From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Notify enhancement |
Date: | 2006-12-04 15:02:12 |
Message-ID: | 878xhnn1qj.fsf@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> Alvaro Herrera wrote:
>>> What will happen when the ring is full? NOTIFY blocks?
>>>
>> An error, I think, don't you? Blocking seems totally unacceptable.
>
> That seems like a curious answer. Imagine the documentation:
> "NOTIFY may fail for no reason whatsoever." I'd vote for blocking.
> Otherwise, apps have to treat NOTIFY as an unreliable communication
> mechanism, which reduces its use-case to approximately nil.
This will run into the same issue that bidirectional pipes run into with
deadlocks. The usual approach in Unix for dealing with this is having the
application always -- even while blocked trying to write -- read any pending
input and buffer it in user-space until it has enough to proceed. This may be
hard to arrange in SQL? I think you would need a way for a PL/pgsql to escape
a blocking write and read any pending notifications.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Gurjeet Singh | 2006-12-04 15:10:11 | Re: Facing a problem with SPI |
Previous Message | Andrew Dunstan | 2006-12-04 15:02:11 | Re: Notify enhancement |