From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Re: pg_basebackup ignores the existing data directory permissions |
Date: | 2019-03-29 11:35:49 |
Message-ID: | 7e567320-aa92-079f-d157-5526edf929b4@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/26/19 3:59 AM, Haribabu Kommi wrote:
>
> I am really questioning if we should keep this stuff isolated within
> pg_basebackup or not. At the same time, it may be confusing to have
> BASE_BACKUP only use the permissions inherited from the data
> directory, so some input from folks maintaining an external backup
> tool is welcome.
>
>
> That would be good to hear what other external backup tool authors
> think of this change.
I'm OK with the -g (inherit|none|group) option as implemented. I prefer
the default as it is (inherit), which makes sense since I wrote it that way.
Having BASE_BACKUP set the permissions inside the tar file seems OK as
well. I'm not aware of any external solutions that are using the
replication protocol directly - I believe they all use pg_basebackup, so
I don't think they would need to change anything.
Having said that, I think setting permissions is a pretty trivial thing
to do and there are plenty of possible scenarios that are still not
covered here. I have no objections to the patch but it seems like overkill.
Regards,
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2019-03-29 11:48:09 | fsync error handling in pg_receivewal, pg_recvlogical |
Previous Message | Prabhat Sahu | 2019-03-29 11:25:26 | Inconsistencies in the behavior of CHR() function in PG. |