Re: pg_basebackup option for handling symlinks

I've recently had a possible need for telling pg_basebackup how to
handle symlinks in the remote data directory, instead of ignoring them,
which is what currently happens. Possible options were recreating the
symlink locally (pointing to a file on the local system) or copying the
file the symlink points to. This is mainly useful in scenarios where
configuration files are symlinked from the data directory. Has anyone
else had the need for this? Is it worth pursuing?

On Sun, Jan 8, 2012 at 21:53, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> I've recently had a possible need for telling pg_basebackup how to
> handle symlinks in the remote data directory, instead of ignoring them,
> which is what currently happens.  Possible options were recreating the
> symlink locally (pointing to a file on the local system) or copying the
> file the symlink points to.  This is mainly useful in scenarios where
> configuration files are symlinked from the data directory.  Has anyone
> else had the need for this?  Is it worth pursuing?

Yes.

I came up to the same issue though - in one case it would've been best
to copy the link, in the other case it would've been best to copy the
contents of the file :S Couldn't decide which was most important...
Maybe a switch would be needed?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On sön, 2012-01-08 at 22:22 +0100, Magnus Hagander wrote:
> On Sun, Jan 8, 2012 at 21:53, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> > I've recently had a possible need for telling pg_basebackup how to
> > handle symlinks in the remote data directory, instead of ignoring them,
> > which is what currently happens. Possible options were recreating the
> > symlink locally (pointing to a file on the local system) or copying the
> > file the symlink points to. This is mainly useful in scenarios where
> > configuration files are symlinked from the data directory. Has anyone
> > else had the need for this? Is it worth pursuing?
>
> Yes.
>
> I came up to the same issue though - in one case it would've been best
> to copy the link, in the other case it would've been best to copy the
> contents of the file :S Couldn't decide which was most important...
> Maybe a switch would be needed?

Yes. Do we need to preserve the third behavior of ignoring symlinks?

tar has an -h option that causes symlinks to be followed. The default
there is to archive the symlink itself.

On Mon, Jan 16, 2012 at 19:52, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On sön, 2012-01-08 at 22:22 +0100, Magnus Hagander wrote:
>> On Sun, Jan 8, 2012 at 21:53, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> > I've recently had a possible need for telling pg_basebackup how to
>> > handle symlinks in the remote data directory, instead of ignoring them,
>> > which is what currently happens.  Possible options were recreating the
>> > symlink locally (pointing to a file on the local system) or copying the
>> > file the symlink points to.  This is mainly useful in scenarios where
>> > configuration files are symlinked from the data directory.  Has anyone
>> > else had the need for this?  Is it worth pursuing?
>>
>> Yes.
>>
>> I came up to the same issue though - in one case it would've been best
>> to copy the link, in the other case it would've been best to copy the
>> contents of the file :S Couldn't decide which was most important...
>> Maybe a switch would be needed?
>
> Yes.  Do we need to preserve the third behavior of ignoring symlinks?

I don't think we do.

> tar has an -h option that causes symlinks to be followed.  The default
> there is to archive the symlink itself.

Seems like a reasonable pattern to follow (though I think using -h is
a really bad idea, but the pattern of by default archiving the symlink
itself)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/