Fujii Masao <masao.fu...@gmail.com> writes: > On Wed, Jul 2, 2014 at 11:39 PM, Joe Conway <m...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers