Re: Audit of logout - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Audit of logout
Date
Msg-id 21396.1404331287@sss.pgh.pa.us
Whole thread Raw
In response to Re: Audit of logout  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Audit of logout  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Fujii Masao <masao.fujii@gmail.com> writes:
> On Wed, Jul 2, 2014 at 11:39 PM, Joe Conway <mail@joeconway.com> wrote:
>> Returned with Feedback means, well exactly that ;-) -- the patch as
>> linked to the CF page is wrong and cannot be applied the way it is
>> currently. It is therefore returned to you to be fixed. It does not
>> mean "Rejected" which is what you seem to infer.

> I think that we should use "Waiting on Author" in that case.

I don't think there's a huge distinction between Waiting on Author and
Returned with Feedback.  The former means we think the author will
probably submit a new version shortly, the latter means we think it'll
take awhile, but in any particular case those predictions could turn
out wrong.  I don't have a problem with moving a patch from Returned with
Feedback back to Needs Review if the author is able to turn it around
while the CF is still going on.

As far as the particular case goes, it strikes me that the real issue
here is that we're confusing privilege level with time-duration of the
setting's effect.  The point of marking log_connections as PGC_BACKEND is
that changing it within a session after a given session starts is useless,
and it's probably better to freeze it so it can tell you what was actually
done by the current session.  The point of marking log_disconnections as
PGC_BACKEND is so that you can freeze the determination of whether a given
session will log its disconnection at the same time that its determination
of whether to log its connection got frozen, and thus ensure that each
connection log entry should eventually have a disconnection log entry,
assuming you have both enabled.  These considerations are not invalidated
by questions of which users should be allowed to adjust the value.

In short, maybe we ought to invent a new category PGC_SU_BACKEND (not
wedded to this spelling), which is to PGC_BACKEND as PGC_SUSET is to
PGC_USERSET, ie same when-it-can-be-changed behavior but only superusers
are allowed to change it.  I don't have any objection to making these two
settings only adjustable by superusers --- I just don't want to give up
the existing timing restrictions for them.

(If we did this, there are probably some other settings that should become
PGC_SU_BACKEND, eg session_preload_libraries ...)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Gavin Flower
Date:
Subject: Re: gaussian distribution pgbench
Next
From: Tom Lane
Date:
Subject: Re: Aggregate function API versus grouping sets