Matt Newell <> writes:
> 1. When a connection issues it's first LISTEN command, in 
> Exec_ListenPreCommit        
> this causes the connection to iterate through every notify queued in the 
> slru, 
> even though at that point I believe the connection can safely ignore any 
> notifications from transactions that are already committed, and if I 
> understand correctly notifications aren't put into the slru until precommit,  
> so wouldn't it be safe to do:
> inside Async_Listen?

Per the comment in Exec_ListenPreCommit, the goal here is to see entries
that have been made and not yet committed.  If you don't do it like this,
then a new listener has the possibility of receiving notifications from
one transaction, while not seeing notifications from another one that
committed later, even though longer-established listeners saw outputs from
both transactions.  We felt that that sort of application-visible
inconsistency would be a bad thing.

> If that's not safe, then could a new member be added to 
> AsyncQueueControl that points to the first uncommitted QueuePosition 
> (wouldn't 
> have to be kept completely up to date).

Err ... isn't that QUEUE_TAIL already?  I've not studied this code in
detail recently, though.

> 2. Would it be possible when a backend is signaled to check if it is idle 
> inside an aborted transaction, and if so process the notifications and put 
> any 
> that match what the backend is listening on into a local list.

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 a whole
bunch of processes to do work at the same time.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to