On Thu, Oct 06, 2005 at 01:32:32AM -0400, Neil Conway wrote:
> On Thu, 2005-06-10 at 01:14 -0400, Tom Lane wrote:
> > The idea of blocking during commit until shmem becomes available might
> > work. There's some issues here about transaction atomicity, though:
> > how do you guarantee that all or none of your notifies get sent?
> > (Actually, supposing that the notifies ought to be sent post-commit,
> > "all" is the only acceptable answer. So maybe you just never give up.)
>
> Yeah, I think that would work. We could also write to shared memory
> before the commit proper, and embed an XID in the message to allow other
> backends to determine when/if to fire the notification.
>
> However, I don't really like the idea of blocking the backend for a
> potentially significant amount of time in a state half-way between
> "committed" and "ready for the next query".
I don't like the idea of blocking indefinitely. It means another global
DOS tool for anybody trying to NOTIFY: just do a LISTEN and sit there
doing nothing.
One idea would be to block for a while, with a timeout. If it expires,
the receiving backend(s) has to copy the notification to local memory
and lets go of the one in shared memory.
--
Alvaro Herrera http://www.advogato.org/person/alvherre
"I'm always right, but sometimes I'm more right than other times."
(LinusTorvalds)