From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Yeb Havinga <yebhavinga(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sync Rep and shutdown Re: Sync Rep v19 |
Date: | 2011-03-16 05:43:50 |
Message-ID: | AANLkTikwH3TTrLnyvamCwUf=M92H-b5+DRWJ9x6nKW0Z@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 16, 2011 at 11:07 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> The problem is that there may be another backend B waiting on a lock
> held by A. If backend A exits cleanly (without a PANIC), it will
> remove itself from the ProcArray and release locks. That wakes up A,
> which can now go do its thing. If the operating system is a bit on
> the slow side delivering the signal to B, then the client to which B
> is connected might manage to see a database state that shows the
> transaction previous running in A as committed, even though that
> transaction wasn't committed. That would stink, because the whole
> point of having A hold onto locks until the standby ack'd the commit
> was that no other transaction would see it as committed until it was
> replicated.
The lock can be released also when the transaction running in A is
rollbacked. So I could not understand why the client wrongly always
see the transaction as commtted even though it's not committed.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2011-03-16 07:29:50 | Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause, |
Previous Message | Devrim GÜNDÜZ | 2011-03-16 05:09:02 | Re: Flex output missing from 9.1a4 tarballs? |