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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2010-02-16 13:11:15 | Re: OpenVMS? |
Previous Message | Hitoshi Harada | 2010-02-16 12:52:12 | Re: ToDo: plpgsql plugin for query and expression verification |