From: | Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> |
---|---|
To: | Hannu Krosing <hannu(at)tm(dot)ee> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: 7.2 items |
Date: | 2001-05-14 09:24:31 |
Message-ID: | 3.0.5.32.20010514172431.009afca0@192.228.128.13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At 10:24 AM 14-05-2001 +0500, Hannu Krosing wrote:
>Lincoln Yeoh wrote:
>> 2) Some form of synchronous "wait" which blocks till an event happens (no
>> need to poll at all).
>> e.g.
>> WAIT('sendmessagetomain');
>>
>> NOTIFY('sendmessagetomain') gets things going. If not possible to reuse
>> NOTIFY, then something else will do.
>>
>> This allows many programs on various hosts to wait for an event before
>> doing things.
>>
>> The present async-io stuff has traces of polling left, can't be done in a
>> transaction and can't be used with Perl DBI (and maybe other standard DB
>> interfaces).
>
>What do you do if you are waiting on come other message - drop it,
>reorder
>messages, something else ?
Since the proposed WAIT is to block on a particular message immediately,
you can't really wait on other messages at the same time. Multiple WAITs
will just be done in the order issued.
It can be considered to be a waste of one backend/db connection, but it
allows some things to be much simpler - each program just does one thing,
and hopefully does it well.
WAIT should return a TRUE if successful - received desired event and
stopped blocking, and a FALSE if not - something else happened (SIGTERM,
backend disconnected/died), and stopped blocking.
Hmm hang on, what will happen if pgsql is shutdown. Tons of WAITing
processes waking up at the same time? Use FreeBSD? :).
Cheerio,
Link.
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2001-05-14 09:48:24 | Re: bug in PLPGSQL |
Previous Message | Christopher Kings-Lynne | 2001-05-14 08:41:56 | Updating system catalogs after a tuple deletion |