Amit Kapila amit.kapil...@gmail.com 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
On Wed, Sep 3, 2014 at 8:09 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Aug 28, 2014 at 11:23 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Wed, Aug 27, 2014 at 5:19 PM, Fujii Masao masao.fu...@gmail.com
wrote:
On Sat, Aug 23, 2014 at 3:44 PM, Amit Kapila
On Thu, Aug 28, 2014 at 11:23 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Wed, Aug 27, 2014 at 5:19 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Aug 23, 2014 at 3:44 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Tue, Aug 5, 2014 at 8:04 PM, Fujii Masao masao.fu...@gmail.com
On Wed, Aug 27, 2014 at 5:19 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Aug 23, 2014 at 3:44 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Tue, Aug 5, 2014 at 8:04 PM, Fujii Masao masao.fu...@gmail.com
wrote:
Changing PGC_SU_BACKEND parameter (log_connections) is
visible even
On Sat, Aug 23, 2014 at 3:44 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Tue, Aug 5, 2014 at 8:04 PM, Fujii Masao masao.fu...@gmail.com wrote:
Yep, the attached patch introduces PGC_SU_BACKEND and
changes the contexts of log_connections and log_disconnections
to PGC_SU_BACKEND. Review?
On Tue, Aug 5, 2014 at 8:04 PM, Fujii Masao masao.fu...@gmail.com 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
!
On Tue, Jul 15, 2014 at 10:45 PM, Magnus Hagander mag...@hagander.net wrote:
On Wed, Jul 2, 2014 at 10:52 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Jul 28, 2014 at 12:22 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Thu, Jul 3, 2014 at 1:13 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Jul 2, 2014 at 11:39 PM, Joe Conway m...@joeconway.com wrote:
No. If we change it to PGC_SIGHUP, SHOW command does display
the changed
On Thu, Jul 3, 2014 at 1:13 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Jul 2, 2014 at 11:39 PM, Joe Conway m...@joeconway.com 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
On Wed, Jul 2, 2014 at 10:52 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Jun 23, 2014 at 5:42 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Jun 21, 2014 at 12:59 PM, Joe Conway m...@joeconway.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/13/2014 07:29 AM, Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
On Thu, Jun 12,
-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. So I
On Wed, Jul 2, 2014 at 11:39 PM, Joe Conway m...@joeconway.com 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
-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 NOT be
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
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
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 two
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 if there's an
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 the
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 really *don't*
-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 how I
On Mon, Jun 23, 2014 at 5:42 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Jun 21, 2014 at 12:59 PM, Joe Conway m...@joeconway.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/13/2014 07:29 AM, Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
On Thu, Jun 12,
On Sat, Jun 21, 2014 at 12:59 PM, Joe Conway m...@joeconway.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/13/2014 07:29 AM, Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao
masao.fu...@gmail.com wrote:
Some users enable
On Fri, Jun 13, 2014 at 11:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao masao.fu...@gmail.com wrote:
Some users enable log_disconnections in postgresql.conf to audit all
logouts.
But since log_disconnections
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/13/2014 07:29 AM, Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao
masao.fu...@gmail.com wrote:
Some users enable log_disconnections in postgresql.conf to
audit all logouts. But since
On Mon, Jun 16, 2014 at 4:14 PM, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Fujii Masao masao.fu...@gmail.com 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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Fujii Masao masao.fu...@gmail.com 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
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
On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao masao.fu...@gmail.com 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
Fujii Masao masao.fu...@gmail.com writes:
On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao masao.fu...@gmail.com 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.
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
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
