From: | Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Synchronous LISTEN/NOTIFY? |
Date: | 2001-01-05 04:13:00 |
Message-ID: | 3.0.5.32.20010105121300.00933e90@192.228.128.13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
At 10:47 PM 04-01-2001 -0500, you wrote:
>Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> writes:
>> Basically LISTEN doesn't wait.
>
>LISTEN has nothing to do with waiting. It merely informs the backend
>of your interest in subsequently receiving notices of a particular type.
>Perhaps you should think of it as like signal(2).
My fault - poor phrasing.
>See
>http://www.postgresql.org/devel-corner/docs/postgres/libpq-notify.htm
>but in brief the idea is:
>
>1. The outer event loop of your application uses select() to wait on
>the PQsocket() fd as well as any other interesting fds.
>
>2. When you see input ready on the PQsocket() fd, call PQconsumeInput(),
>then check PQnotifies().
>
>3. Also check PQnotifies() after any PQexec(), to see if notify messages
>came in during the query.
>
>Keep in mind also that notifications are only delivered when you are
>not within a transaction block (BEGIN/END).
Uhoh, since I'm using perl does that mean I have to patch DBI and Pg::DBD?
And worse - turn off transactions.
Would it be viable idea to add a WAIT command/statement for higher level
access (e.g. "SQL" level access to this feature)?
e.g.
WAIT "blahblahblah";
where it will wait until a NOTIFY "blahblahblah".
That'll be real nice to have :). If I start messing about with PQstuff I'll
probably screw up somewhere.
Thanks anyway,
Link.
From | Date | Subject | |
---|---|---|---|
Next Message | GH | 2001-01-05 04:26:52 | Re: How passwords can be crypted in postgres? |
Previous Message | Lamar Owen | 2001-01-05 04:07:56 | Re: 7.0.3 rpm testing & other problems |