Automatically recreate empty pg_xxx folders if they don't exist

I was restoring GitLab from an S3 bucket today and after I moved all the files to a new server, GitLab failed to start. In addition to !1706 (merged) (which seems solvable), another error was related to the lack of a few empty sub-directories in /var/opt/gitlab/postgresql.

Because s3 does not have a concept of directory (just like git), doing aws s3 sync --delete /path/to/gitlab/data s3://gitlab-backup/path/to/gitlab/data --no-follow-symlinks does on the source server did not backup empty directories such as /var/opt/gitlab/postgresql/pg_tblspc. So, when the data was restored on a new machine with aws s3 sync --delete s3://gitlab-backup/path/to/gitlab/data /path/to/gitlab/data --no-follow-symlinks, the instance did not start. The logs contained variations of the following:

==> /var/log/gitlab/postgresql/current <==
FATAL:  could not open directory "pg_tblspc": No such file or directory
LOG:  database system is shut down
FATAL:  could not open directory "pg_tblspc": No such file or directory
LOG:  database system is shut down
FATAL:  could not open directory "pg_tblspc": No such file or directory
LOG:  database system is shut down

==> /var/log/gitlab/postgresql/current <==
LOG:  request to flush past end of generated WAL; request 98/35001F28, currpos 96/9C000000
CONTEXT:  writing block 124 of relation base/16400/16803
ERROR:  xlog flush request 98/35001F28 is not satisfied --- flushed only to 96/9C000000
CONTEXT:  writing block 124 of relation base/16400/16803
WARNING:  could not write block 124 of base/16400/16803
DETAIL:  Multiple failures --- write error might be permanent.
LOG:  request to flush past end of generated WAL; request 98/35001F28, currpos 96/9C000000

It seems that the only cure at the moment is to manually re-create all the missing subdirectories of /var/opt/gitlab/postgresql, which was a pretty long list in my case.

cd /var/opt/gitlab/postgresql # or whatever matching dir on the host server
mkdir -p pg_commit_ts
mkdir -p pg_dynshmem
mkdir -p pg_logical/mappings
mkdir -p pg_logical/snapshots
mkdir -p pg_replslot
mkdir -p pg_serial
mkdir -p pg_snapshots
mkdir -p pg_stat
mkdir -p pg_tblspc
mkdir -p pg_twophase

I was able to reconstruct this list manually through trial and error by comparing the target directory with the source one (thanks to that the source server was still alive). After all the dirs were created, it was also necessary to call the update-permissions script.

How can the process of restoring empty postgres directories be automated so that others did not have to spend time on investigation? Maybe postgres is not the only component that crashes without particular empty dirs, I just haven't noticed others yet?