Re: feature request: consume asynchronous notification via a function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: feature request: consume asynchronous notification via a function
Date: 2017-11-21 18:20:23
Message-ID: 13202.1511288423@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Nov 21, 2017 at 11:32 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> I am very much looking at the new stored procedure functionality and
>> imaging a loop like this:
>>
>> LOOP
>> FOR r IN SELECT * FROM pg_get_notifications(30)
>> LOOP
>> PERFORM do_stuff(r);
>> END LOOP;
>> COMMIT; -- advance xmin etc
>> END LOOP;

> Yeah, if you keep the timeout fairly short, it would probably work OK
> (with Peter's stuff).

Traditionally, NOTIFY messages are delivered to the client only between
transactions, so that there is no question about whether the
message-delivery should roll back if the surrounding transaction aborts.
It's not very clear to me what the behavior of pg_get_notifications()
inside a transaction ought to be. Is it OK if it's a volatile function
and the messages are just gone once the function has returned them,
even if you fail to do anything about them because your transaction
fails later?

(I'd be against having a function that returns more than one at a time,
in any case, as that just complicates matters even more.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2017-11-21 18:22:04 Re: Does XMLSERIALIZE output xmlattributes in a stable order?
Previous Message Robert Haas 2017-11-21 18:19:58 Re: View with duplicate GROUP BY entries