Amit Kapila writes:
> Yes, it was failing only on windows. Today when I further tried to
> look into the issue, I found that if I rebuild plpgsql, it didn't occurred.
> So the conclusion is that it occurred due to build mismatch, however I
> am not sure why a rebuild of plpgsql is required for th
On Wed, Sep 3, 2014 at 8:09 PM, Fujii Masao wrote:
>
> On Thu, Aug 28, 2014 at 11:23 PM, Amit Kapila
wrote:
> > On Wed, Aug 27, 2014 at 5:19 PM, Fujii Masao
wrote:
> >>
> >> On Sat, Aug 23, 2014 at 3:44 PM, Amit Kapila
> >> wrote:
> >> > On Tue, Aug 5, 2014 at 8:04 PM, Fujii Masao
> >> > wrote
On Thu, Aug 28, 2014 at 11:23 PM, Amit Kapila wrote:
> On Wed, Aug 27, 2014 at 5:19 PM, Fujii Masao wrote:
>>
>> On Sat, Aug 23, 2014 at 3:44 PM, Amit Kapila
>> wrote:
>> > On Tue, Aug 5, 2014 at 8:04 PM, Fujii Masao
>> > wrote:
>> > Changing PGC_SU_BACKEND parameter (log_connections) is
>> > v
On Wed, Aug 27, 2014 at 5:19 PM, Fujii Masao wrote:
>
> On Sat, Aug 23, 2014 at 3:44 PM, Amit Kapila
wrote:
> > On Tue, Aug 5, 2014 at 8:04 PM, Fujii Masao
wrote:
> > Changing PGC_SU_BACKEND parameter (log_connections) is
> > visible even with a non-super user client due to above code.
> > Shoul
On Sat, Aug 23, 2014 at 3:44 PM, Amit Kapila wrote:
> On Tue, Aug 5, 2014 at 8:04 PM, Fujii Masao wrote:
>>
>> Yep, the attached patch introduces PGC_SU_BACKEND and
>> changes the contexts of log_connections and log_disconnections
>> to PGC_SU_BACKEND. Review?
>>
Thanks for reviewing the patch!
On Tue, Aug 5, 2014 at 8:04 PM, Fujii Masao wrote:
>
> Yep, the attached patch introduces PGC_SU_BACKEND and
> changes the contexts of log_connections and log_disconnections
> to PGC_SU_BACKEND. Review?
>
1.
! else if (context != PGC_POSTMASTER && context != PGC_SU_BACKEND &&
! context != PGC_SU
On Tue, Jul 15, 2014 at 10:45 PM, Magnus Hagander wrote:
> On Wed, Jul 2, 2014 at 10:52 PM, Tom Lane wrote:
>> I wrote:
>>> 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-
On Mon, Jul 28, 2014 at 12:22 PM, Amit Kapila wrote:
> On Thu, Jul 3, 2014 at 1:13 AM, Fujii Masao wrote:
>> On Wed, Jul 2, 2014 at 11:39 PM, Joe Conway wrote:
>>
>> No. If we change it to PGC_SIGHUP, SHOW command does display
>> the changed value after a reload. It's the same behavior as other
On Thu, Jul 3, 2014 at 1:13 AM, Fujii Masao wrote:
> On Wed, Jul 2, 2014 at 11:39 PM, Joe Conway wrote:
>
> No. If we change it to PGC_SIGHUP, SHOW command does display
> the changed value after a reload. It's the same behavior as other
> PGC_SIGHUP parameters do. Attached patch just changes it t
On Wed, Jul 2, 2014 at 10:52 PM, Tom Lane wrote:
> I wrote:
>> 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/02/2014 02:15 PM, Abhijit Menon-Sen wrote:
> At 2014-07-02 16:47:16 -0400, alvhe...@2ndquadrant.com wrote:
>>
>> If we expect that the author is going to update the patch, the
>> right state to use is "Waiting on author".
>
> Quite so. That's h
Abhijit Menon-Sen wrote:
> At 2014-07-02 16:47:16 -0400, alvhe...@2ndquadrant.com wrote:
> >
> > If we expect that the author is going to update the patch, the right
> > state to use is "Waiting on author".
>
> Quite so. That's how I understand it, and what I've been doing. But what
> if we reall
At 2014-07-02 16:47:16 -0400, alvhe...@2ndquadrant.com wrote:
>
> If we expect that the author is going to update the patch, the right
> state to use is "Waiting on author".
Quite so. That's how I understand it, and what I've been doing. But what
if we really *don't* expect the author to update t
Abhijit Menon-Sen wrote:
> At 2014-07-02 12:52:51 -0700, m...@joeconway.com wrote:
> >
> > Doesn't mean that to me but feel free to change it to Waiting on
> > Author if you prefer :-)
> >
> > Is there any official explanation as to what those states mean
> > documented anywhere?
>
> I don't know
I wrote:
> 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
At 2014-07-02 12:52:51 -0700, m...@joeconway.com wrote:
>
> Doesn't mean that to me but feel free to change it to Waiting on
> Author if you prefer :-)
>
> Is there any official explanation as to what those states mean
> documented anywhere?
I don't know if there's an official definition, but my
Fujii Masao writes:
> On Wed, Jul 2, 2014 at 11:39 PM, Joe Conway 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 "Rej
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/02/2014 12:43 PM, Fujii Masao wrote:
> I think that we should use "Waiting on Author" in that case.
>
> "Returned with Feedback" is not "Rejected". That's right. But it
> basically means that the bugfixed or revised version of the patch
> will N
On Wed, Jul 2, 2014 at 11:39 PM, Joe Conway wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/01/2014 11:55 PM, Fujii Masao wrote:
>> Hmm... I found that you had marked this proposal as "Returned with
>> Feedback". But I don't think that we reached the consensus to do
>> that. I t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/01/2014 11:55 PM, Fujii Masao wrote:
> Hmm... I found that you had marked this proposal as "Returned with
> Feedback". But I don't think that we reached the consensus to do
> that. I think that it's still worth discussing this topic in this
> CF.
On Mon, Jun 23, 2014 at 5:42 PM, Fujii Masao wrote:
> On Sat, Jun 21, 2014 at 12:59 PM, Joe Conway wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 06/13/2014 07:29 AM, Tom Lane wrote:
>>> Fujii Masao writes:
On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao
wrote:
>
On Mon, Jun 23, 2014 at 5:42 PM, Fujii Masao wrote:
> On Sat, Jun 21, 2014 at 12:59 PM, Joe Conway wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 06/13/2014 07:29 AM, Tom Lane wrote:
>>> Fujii Masao writes:
On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao
wrote:
>
On Sat, Jun 21, 2014 at 12:59 PM, Joe Conway wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/13/2014 07:29 AM, Tom Lane wrote:
>> Fujii Masao writes:
>>> On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao
>>> wrote:
Some users enable log_disconnections in postgresql.conf to
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/13/2014 07:29 AM, Tom Lane wrote:
> Fujii Masao writes:
>> On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao
>> wrote:
>>> Some users enable log_disconnections in postgresql.conf to
>>> audit all logouts. But since log_disconnections is defined with
On Fri, Jun 13, 2014 at 11:29 PM, Tom Lane wrote:
> Fujii Masao writes:
>> On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao wrote:
>>> Some users enable log_disconnections in postgresql.conf to audit all
>>> logouts.
>>> But since log_disconnections is defined with PGC_BACKEND, it can be changed
>>
On Mon, Jun 16, 2014 at 4:14 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Fujii Masao writes:
>> > That's harmful for audit purpose. I think that we should make
>> > log_disconnections PGC_SUSET rather than PGC_BACKEND in order
>> > to forbid non-superusers from changing i
At 2014-06-13 10:29:24 -0400, t...@sss.pgh.pa.us wrote:
>
> I wonder whether we should just get rid of log_disconnections as a
> separate variable, instead logging disconnections when log_connections
> is set.
I like that idea.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Fujii Masao writes:
> > That's harmful for audit purpose. I think that we should make
> > log_disconnections PGC_SUSET rather than PGC_BACKEND in order
> > to forbid non-superusers from changing its setting. Attached
> > patch does this.
I tend to agree wi
Tom Lane-2 wrote
> Another answer is to make both variables PGC_SIGHUP, on the grounds
> that it doesn't make much sense for them not to be applied system-wide;
> except that I think there was some idea that logging might be enabled
> per-user or per-database using ALTER ROLE/DATABASE.
>From a tro
Fujii Masao writes:
> On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao wrote:
>> Some users enable log_disconnections in postgresql.conf to audit all logouts.
>> But since log_disconnections is defined with PGC_BACKEND, it can be changed
>> at connection start. This means that any client (even nonsup
On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao wrote:
> Hi,
>
> Some users enable log_disconnections in postgresql.conf to audit all logouts.
> But since log_disconnections is defined with PGC_BACKEND, it can be changed
> at connection start. This means that any client (even nonsuperuser) can freely
Hi,
Some users enable log_disconnections in postgresql.conf to audit all logouts.
But since log_disconnections is defined with PGC_BACKEND, it can be changed
at connection start. This means that any client (even nonsuperuser) can freely
disable log_disconnections not to log his or her logout even
32 matches
Mail list logo
