Re: Synchronous LISTEN/NOTIFY?
От | Lincoln Yeoh |
---|---|
Тема | Re: Synchronous LISTEN/NOTIFY? |
Дата | |
Msg-id | 3.0.5.32.20010105121300.00933e90@192.228.128.13 обсуждение исходный текст |
Ответ на | Re: Synchronous LISTEN/NOTIFY? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Synchronous LISTEN/NOTIFY?
|
Список | pgsql-general |
At 10:47 PM 04-01-2001 -0500, you wrote: >Lincoln Yeoh <lyeoh@pop.jaring.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.
В списке pgsql-general по дате отправления: