Re: Re: 7.2 items

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.

In response to

Responses

Browse pgsql-hackers by date

  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