Re: [GENERAL] NOTIFY command impact - Mailing list pgsql-general

From Rob Brucks
Subject Re: [GENERAL] NOTIFY command impact
Date
Msg-id E0744EE6-DFCA-4E6B-A382-EDD52846D55C@rackspace.com
Whole thread Raw
In response to Re: [GENERAL] NOTIFY command impact  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [GENERAL] NOTIFY command impact  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-general
Thank you Tom.

So, long-term, you don't see any negative impacts to the master cluster?

I just don't want to implement this as a streaming "push" mechanism and then have my cluster crash in 12 months because
ithit some obscure problem with notifications.
 

This turned out to be a really simple/elegant way to force WAL stream movement without having to modify the database in
anyway, since I am heavily restricting the permissions granted to my monitoring role.
 

And, on a side note, it would be EXTREMELY useful to include a default monitoring role in PG that has permission to
queryall columns of all pg_stat* views on any DB, yet has no ability to modify *anything* (not even create any objects
ofits own). I won't grant super-user to my monitoring role since it is administered remotely, it is too much of a
securityrisk.
 

Thanks!
Rob

On 2/22/17, 3:19 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:

    =?utf-8?Q?Fran=C3=A7ois_Beaulieu?= <frank@TZoNE.ORG> writes:
    >> On Feb 21, 2017, at 6:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
    >> (The reason it goes into the WAL stream is so that you can have listeners
    >> on replication slaves, not for recovery purposes.)
    
    > Are we sure that replication slaves can have listeners? When I tried it on 9.4.10, I got the following message:
    > "ERROR: cannot execute LISTEN during recovery"
    
    Hmm ... you know what, my remark above is full of it.  NOTIFY traffic
    *doesn't* go into the WAL stream.  I think I was remembering some
    discussions about how that would be a good idea so that you could put
    listeners on slaves; but that hasn't actually happened yet, as a look
    through async.c will show.
    
    After thinking a bit more, I believe what the OP is seeing is that
    NOTIFY does result in an XID being assigned to the transaction (so
    that the message it sticks into the pg_notify queue can be correctly
    labeled).  That therefore results in a transaction commit message
    being sent to WAL, even though this transaction did nothing that would
    actually change any persistent database state.
    
    There are other ways of forcing XID assignment without doing much
    real work, but this one is probably about as cheap as any.
    
                regards, tom lane
    


pgsql-general by date:

Previous
From: Jeff Janes
Date:
Subject: Re: [GENERAL] Autovacuum stuck for hours, blocking queries
Next
From: Jeff Janes
Date:
Subject: Re: [GENERAL] bloat indexes - opinion