Horton

Re: Sync Rep and shutdown Re: Sync Rep v19

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Yeb Havinga <yebhavinga@gmail.com>, Jaime Casanova <jaime@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-03-16T11:38:44Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Document guc context values, and reference them from the config doc section.

On Wed, Mar 16, 2011 at 1:43 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Wed, Mar 16, 2011 at 11:07 AM, Robert Haas <robertmhaas@gmail.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.

The transaction IS committed, but only locally.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company