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
reason is it makes th
>
> > 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 given
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 that we've had to
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 don't want to release
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 queued in the
> > slru,
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 believe the connection c
