>
> > After further thought, I wonder whether instead of having an incoming
> > listener initialize its "pos" to QUEUE_TAIL, we couldn't have it
> > initialize to the maximum "pos" among existing listeners (with a floor of
> > QUEUE_TAIL of course). If any other listener has advanced over a
Matt Newell writes:
> Patch attached works great. I added the dboid to the QueueBackendStatus
> struct but that might not be needed if there is an easy and fast way to get a
> db oid from a backend pid.
Not particularly; I agree with adding it to this data structure. One
On Monday, September 28, 2015 07:22:26 PM Tom Lane wrote:
> Matt Newell writes:
> > 1. When a connection issues it's first LISTEN command, in
> > Exec_ListenPreCommit QUEUE_BACKEND_POS(MyBackendId) = QUEUE_TAIL;
> > this causes the connection to iterate through every notify
On Tuesday, September 29, 2015 09:58:35 PM Tom Lane wrote:
> Matt Newell writes:
> > On Monday, September 28, 2015 07:22:26 PM Tom Lane wrote:
> >> Possibly. sinval catchup notification works like that, so you could
> >> maybe
> >> invent a similar mechanism for notify. Beware
Matt Newell writes:
> On Monday, September 28, 2015 07:22:26 PM Tom Lane wrote:
>> Possibly. sinval catchup notification works like that, so you could maybe
>> invent a similar mechanism for notify. Beware that we've had to fix
>> performance issues with sinval catchup; you
Matt Newell writes:
> 1. When a connection issues it's first LISTEN command, in
> Exec_ListenPreCommit
> QUEUE_BACKEND_POS(MyBackendId) = QUEUE_TAIL;
> this causes the connection to iterate through every notify queued in the
> slru,
> even though at that point I
This morning with our production database I began receiving reports
of the database being "down".
I checked the log and was surprised to see extremely long durations for a
LISTEN that happens after each connection is made by our database library.
This coincided with many(approx 600) new