Re: Synchronous LISTEN/NOTIFY?

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.

In response to

Responses

Browse pgsql-general by date

  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