On Sun, Mar 24, 2019 at 11:16 PM Michael Paquier
wrote:
> On Fri, Mar 22, 2019 at 01:01:44PM +0900, Michael Paquier wrote:
> > On Fri, Mar 22, 2019 at 02:35:41PM +1100, Haribabu Kommi wrote:
> > > Thanks for the correction. Yes, that is correct and it works fine.
> >
> > Thanks for double-checki
On Sun, Mar 24, 2019 at 09:16:44PM +0900, Michael Paquier wrote:
> After testing and reviewing the patch, I noticed that all versions
> sent up to now missed two things done by logfile_open():
> - Bufferring is line-buffered. For current_logfiles it may not matter
> much as the contents are first
On Fri, Mar 22, 2019 at 01:01:44PM +0900, Michael Paquier wrote:
> On Fri, Mar 22, 2019 at 02:35:41PM +1100, Haribabu Kommi wrote:
> > Thanks for the correction. Yes, that is correct and it works fine.
>
> Thanks for double-checking. Are there any objections with this patch?
Done and committed
On Fri, Mar 22, 2019 at 02:35:41PM +1100, Haribabu Kommi wrote:
> Thanks for the correction. Yes, that is correct and it works fine.
Thanks for double-checking. Are there any objections with this patch?
--
Michael
signature.asc
Description: PGP signature
On Fri, Mar 22, 2019 at 12:24 PM Michael Paquier
wrote:
> On Thu, Mar 21, 2019 at 12:52:14PM +1100, Haribabu Kommi wrote:
> > Earlier attached patch is wrong.
>
> - oumask = umask(pg_file_create_mode);
> + oumask = umask(pg_mode_mask);
> Indeed that was wrong.
>
> > Correct patch attached. So
On Thu, Mar 21, 2019 at 12:52:14PM +1100, Haribabu Kommi wrote:
> Earlier attached patch is wrong.
- oumask = umask(pg_file_create_mode);
+ oumask = umask(pg_mode_mask);
Indeed that was wrong.
> Correct patch attached. Sorry for the inconvenience.
This looks better for the umask setting, sti
On Thu, Mar 21, 2019 at 12:41 PM Haribabu Kommi
wrote:
>
> On Wed, Mar 20, 2019 at 4:33 PM Michael Paquier
> wrote:
>
>> And actually it seems to me that you have a race condition in that
>> stuff. I think that you had better use umask(), then fopen, and then
>> once again umask() to put back t
On Wed, Mar 20, 2019 at 4:33 PM Michael Paquier wrote:
> On Fri, Mar 15, 2019 at 06:51:37PM +1100, Haribabu Kommi wrote:
> > IMO, this update is just a recommendation to the user, and sometimes it
> is
> > still possible that there may be strict permissions for the log file
> > even the data dire
On Fri, Mar 15, 2019 at 06:51:37PM +1100, Haribabu Kommi wrote:
> IMO, this update is just a recommendation to the user, and sometimes it is
> still possible that there may be strict permissions for the log file
> even the data directory is allowed for the group access. So I feel
> it is still bett
On Tue, Mar 12, 2019 at 5:03 PM Michael Paquier wrote:
> On Tue, Feb 26, 2019 at 12:22:53PM +1100, Haribabu Kommi wrote:
> > I checked the code why the current_logfiles is not implemented as
> > shared memory and found that the current syslogger doesn't attach to
> > the shared memory of the post
On Tue, Mar 12, 2019 at 04:08:53PM -0400, Robert Haas wrote:
> Anybody who has permission to read the log files but not the data
> directory will presumably hit the directory-level permissions on
> $PGDATA before the issue of the permissions on current_logfiles() per
> se become relevant, except in
On Tue, Mar 12, 2019 at 2:03 AM Michael Paquier wrote:
> On Tue, Feb 26, 2019 at 12:22:53PM +1100, Haribabu Kommi wrote:
> > I checked the code why the current_logfiles is not implemented as
> > shared memory and found that the current syslogger doesn't attach to
> > the shared memory of the postm
On Tue, Feb 26, 2019 at 12:22:53PM +1100, Haribabu Kommi wrote:
> I checked the code why the current_logfiles is not implemented as
> shared memory and found that the current syslogger doesn't attach to
> the shared memory of the postmaster. To support storing the
> current_logfiles in shared memor
On Mon, Feb 4, 2019 at 12:16 PM Haribabu Kommi
wrote:
>
> And regarding current_logfiles permissions, I feel this file should have
> permissions of data directory files as it is present in the data directory
> whether it stores the information of log file, until this file is
> completely
> remove
On Fri, Feb 1, 2019 at 7:22 PM Michael Paquier wrote:
> On Fri, Jan 18, 2019 at 09:50:40AM -0500, Stephen Frost wrote:
> > Yes, we should update the documentation in this regard, though it's
> > really an independent thing as that documentation should have been
> > updated in the original group-a
On Fri, Jan 18, 2019 at 09:50:40AM -0500, Stephen Frost wrote:
> Yes, we should update the documentation in this regard, though it's
> really an independent thing as that documentation should have been
> updated in the original group-access patch, so I'll see about fixing
> it and back-patching it.
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Fri, Jan 18, 2019 at 09:50:40AM -0500, Stephen Frost wrote:
> > It'd probably be good to give folks an opportunity to voice their
> > opinion regarding their use-case for the file existing as it does and
> > being documented as it is.
On Fri, Jan 18, 2019 at 09:50:40AM -0500, Stephen Frost wrote:
> It'd probably be good to give folks an opportunity to voice their
> opinion regarding their use-case for the file existing as it does and
> being documented as it is. At first blush, to me anyway, it seems like
> maybe this was a cas
Greetings,
* Haribabu Kommi (kommi.harib...@gmail.com) wrote:
> On Thu, Jan 17, 2019 at 5:49 AM Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > Now, if the expectation is that current_logfiles is just an internal
> > > working file that users shouldn't access directly, then
On Thu, Jan 17, 2019 at 5:49 AM Stephen Frost wrote:
> Greetings,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > * Michael Paquier (mich...@paquier.xyz) wrote:
> > >> On Tue, Jan 15, 2019 at 10:53:30AM -0500, Tom Lane wrote:
> > >>> On reflection, maybe the problem is
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Michael Paquier (mich...@paquier.xyz) wrote:
> >> On Tue, Jan 15, 2019 at 10:53:30AM -0500, Tom Lane wrote:
> >>> On reflection, maybe the problem is not that we're giving the file
> >>> the wrong permissions, but tha
Stephen Frost writes:
> * Michael Paquier (mich...@paquier.xyz) wrote:
>> On Tue, Jan 15, 2019 at 10:53:30AM -0500, Tom Lane wrote:
>>> On reflection, maybe the problem is not that we're giving the file
>>> the wrong permissions, but that we're putting it in the wrong place?
> I'm not really sure
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Tue, Jan 15, 2019 at 10:53:30AM -0500, Tom Lane wrote:
> > On reflection, maybe the problem is not that we're giving the file
> > the wrong permissions, but that we're putting it in the wrong place?
> > That is, seems like it should be
On Tue, Jan 15, 2019 at 10:53:30AM -0500, Tom Lane wrote:
> On reflection, maybe the problem is not that we're giving the file
> the wrong permissions, but that we're putting it in the wrong place?
> That is, seems like it should be in the logfile directory not the
> data directory. That would cer
I wrote:
> Haribabu Kommi writes:
>> Excluding the file in the backup can solve the problem of backup by an
>> unprivileged user. Is there any scenarios it can cause problems if it
>> doesn't follow the group access mode?
> The point of this file, as I understood it, was to allow someone who's
>
Haribabu Kommi writes:
> Excluding the file in the backup can solve the problem of backup by an
> unprivileged user. Is there any scenarios it can cause problems if it
> doesn't follow the group access mode?
The point of this file, as I understood it, was to allow someone who's
allowed to read th
On Tue, Jan 15, 2019 at 4:15 PM Michael Paquier wrote:
> On Tue, Jan 15, 2019 at 03:08:41PM +1100, Haribabu Kommi wrote:
> > current_logfiles is a meta data file, that stores the current log writing
> > file, and this file presents in the data directory. This file
> > doesn't follow the group acc
On Tue, Jan 15, 2019 at 03:08:41PM +1100, Haribabu Kommi wrote:
> current_logfiles is a meta data file, that stores the current log writing
> file, and this file presents in the data directory. This file
> doesn't follow the group access mode set at the initdb time, but it
> follows the log_file_mo
current_logfiles is a meta data file, that stores the current log writing
file, and this file
presents in the data directory. This file doesn't follow the group access
mode set at
the initdb time, but it follows the log_file_mode permissions.
without group access permissions, backup with group acc
29 matches
Mail list logo
