Matt Newell <newe...@blur.com> 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 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:
> QUEUE_BACKEND_POS(MyBackendId) = QUEUE_HEAD;
> 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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
