Re: LISTEN/NOTIFY and notification timing guarantees

tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) writes:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> On Tue, Feb 16, 2010 at 10:38 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> 2. Add an extra lock to serialize writers to the queue, so that messages
>>> are guaranteed to be added to the queue in commit order.  As long as
>
>> fwiw, I think you're definitely on the right track. IMO, any scenario
>> where an issued notification ends up being deferred for an indefinite
>> period of time without alerting the issuer should be avoided if at all
>> possible. Just to clarify though, does your proposal block all
>> notifiers if any uncommitted transaction issued a notify?
>
> It will block other notifiers until the transaction releases its locks,
> which should happen pretty promptly --- there are no user-accessible
> reasons for it to wait.

I have heard of reasons to want to be able to have some actions run at
COMMIT time.

You probably recall Jan's proposal of a commit time timestamp. The
particular implementation may have fallen by the wayside, but the
reasons to want such things do continue to be. Indeed an "on commit"
trigger hook would be a mighty valuable thing to support things like
(but not restricted to) commit timestamps.

It's conceivable that "clustering issues" might introduce some somewhat
more "user-accessible" hooks that could cost something here. Certainly
not true today, but plausibly foreseeable...
--
select 'cbbrowne' || '@' || 'linuxfinances.info';
http://www3.sympatico.ca/cbbrowne/lsf.html
Beauty is the first test: there is no permanent place in the world for
ugly mathematics.