Re: LISTEN denial of service with aborted transaction

Matt Newell <newellm(at)blur(dot)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