Re: current_logfiles not following group access and instead follows log_file_mode permissions

Greetings,

* Haribabu Kommi (kommi(dot)haribabu(at)gmail(dot)com) wrote:
> On Thu, Jan 17, 2019 at 5:49 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > > Now, if the expectation is that current_logfiles is just an internal
> > > working file that users shouldn't access directly, then this argument
> > > is wrong --- but then why is it documented in user-facing docs?
> >
> > I really couldn't say why it's documented in the user-facing docs, and
> > for my 2c I don't really think it should be- there's a function to get
> > that information. Sprinkling the data directory with files for users to
> > access directly doesn't exactly fit my view of what a good API looks
> > like.
> >
> > The fact that there isn't any discussion about where that file actually
> > lives does make me suspect you're right that log files outside the data
> > directory wasn't really contemplated.
>
> I can only think of reading this file by the user directly when the server
> is not available, but I don't find any scenario where that is required?

Yeah, I agree, and if the server isn't running then there really isn't
a "current" logfile, as defined, since the server isn't writing to any
particular log file.

> > > If we're going to accept the patch as-is, then it logically follows
> > > that we should de-document current_logfiles, because we're taking the
> > > position that it's an internal temporary file not meant for user access.
> >
> > ... and hopefully we'd get rid of it one day entirely.
>
> If there is no use of it when server is offline, it will be better to
> remove that
> file with an alternative to provide the current log file name.

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 case of "over-documenting" of the feature by including
in user-facing documentation something that was really there for
internal reasons, but I could certainly be wrong and maybe there's a
reason why it's really necessary to have the file around for users.

> With group access mode, the default value of log_file_mode is changed,
> Attached patch reflects the same in docs.

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.

Thanks!

Stephen