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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Postgresql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Use of 'cp -r' in CREATE DATABASE
Date: 2003-12-15 22:56:36
Message-ID: 200312152256.hBFMuao12799@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


I added this comment to the code in case we don't fix cp -r:

/* We might need to use cp -R one day for portability */

---------------------------------------------------------------------------

Tom Lane wrote:
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-12-15 23:10:03 Re: conversion_create.sql
Previous Message Tom Lane 2003-12-15 22:33:33 Re: Postgres 7.3.5 and count('x')