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

Re: LISTEN/NOTIFY and notification timing guarantees

From: Joachim Wieland <joe(at)mcknight(dot)de>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: LISTEN/NOTIFY and notification timing guarantees
Date: 2010-02-16 13:03:13
Message-ID: dc7b844e1002160503t255b97c1n8a545eced38e0673@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Feb 16, 2010 at 1:31 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Tom Lane  wrote:
>> We could adopt the historical policy of sending self-notifies
>> pre-commit, but that doesn't seem tremendously appetizing from the
>> standpoint of transactional integrity.
>
> But one traditional aspect of transactional integrity is that a
> transaction always sees *its own* uncommitted work.

True but notifications aren't sent until the transaction commits
anyway. At the time when an application receives its self-notifies, it
has already committed the transaction so there is no uncommitted work
anymore.


> Wouldn't the
> historical policy of PostgreSQL self-notifies be consistent with
> that?

No. The policy is also to not see the committed work if for some
reason the transaction had to roll back during commit. In this case
we'd also expect getting no notification from this transaction at all
and this is what is violated here.


Joachim

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2010-02-16 13:11:15
Subject: Re: OpenVMS?
Previous:From: Hitoshi HaradaDate: 2010-02-16 12:52:12
Subject: Re: ToDo: plpgsql plugin for query and expression verification

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