Re: Use of 'cp -r' in CREATE DATABASE

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> IIRC we don't copy anything but plain files and directories - no special
> files, symlinks or fifos, so the -R/-r differences shouldn't affect us
> anyway, should they? Also, that should make the implementation of an
> internal recursive copy much simpler - far fewer cases to consider.

In the ordinary case, yes. There could perhaps be hand-created symlinks
in the source directory, but I think we would actually prefer that the
copy be stupid about such things (copy the referenced file rather than
duplicating the symlink). Special files would be a reason to error out.

Also, I'm not sure that there's any good reason to recurse into
subdirectories. The only subdirectory a database dir could have at
present is the temp-file one, and we'd really prefer that that *not* be
copied at all.

A final point is that implementing CREATE DATABASE via "cp -r" is and
always has been fundamentally broken anyway, because of the lack of
interlocking against other backends changing the source database.
We have a very half-baked defense against that (erroring out if anyone
else is connected to the source DB at the start of the copy) which
I would dearly love to get rid of. With a file-by-file copy, it might
be possible to do better. (I'm wondering if there's any way to take
ShareLocks on the individual tables we are copying --- if we could
figure out their OIDs we could do this, but relfilenode is not OID.)

These considerations might change somewhat when we get around to
implementing tablespaces, but I think it's likely that that will
make the need for a custom copy implementation greater, not less.

regards, tom lane