Re: fixing LISTEN/NOTIFY

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fixing LISTEN/NOTIFY
Date: 2005-10-06 05:32:32
Message-ID: 1128576752.9140.56.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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".

-Neil

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Devrim GUNDUZ 2005-10-06 06:16:10 Re: Slony RPM issue
Previous Message Tom Lane 2005-10-06 05:14:56 Re: fixing LISTEN/NOTIFY