From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Matt Newell <newellm(at)blur(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, it(at)blur(dot)com, codefoo(at)blur(dot)com |
Subject: | Re: LISTEN denial of service with aborted transaction |
Date: | 2015-09-28 23:22:26 |
Message-ID: | 12685.1443482546@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2015-09-28 23:41:06 | Re: No Issue Tracker - Say it Ain't So! |
Previous Message | Jim Nasby | 2015-09-28 23:17:18 | Re: No Issue Tracker - Say it Ain't So! |