Re: Use of 'cp -r' in CREATE DATABASE - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Use of 'cp -r' in CREATE DATABASE
Date
Msg-id 200312152256.hBFMuao12799@candle.pha.pa.us
Whole thread Raw
In response to Re: Use of 'cp -r' in CREATE DATABASE  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@dunslane.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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Postgres 7.3.5 and count('x')
Next
From: Tom Lane
Date:
Subject: Re: conversion_create.sql