Skip site navigation (1) Skip section navigation (2)

Re: LISTEN/NOTIFY and notification timing guarantees

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: LISTEN/NOTIFY and notification timing guarantees
Date: 2010-02-16 23:13:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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' || '@' || '';
Beauty is the first test: there is no permanent place in the world for
ugly mathematics.

In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2010-02-16 23:13:35
Subject: Re: XQuery support
Previous:From: Alvaro HerreraDate: 2010-02-16 23:12:30
Subject: Re: Problem with 8.4 stats collector high load

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group