On Thu, Jul 28, 2011 at 3:40 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote:
> On Thu, 2011-07-28 at 21:32 +0200, Hannu Krosing wrote:
>> On Thu, 2011-07-28 at 14:27 -0400, Robert Haas wrote:
>>
>> > Hmm, interesting idea. However, consider the scenario where some
>> > transactions are using synchronous_commit or synchronous replication,
>> > and others are not. If a transaction that needs to wait (either just
>> > for WAL flush, or for WAL flush and synchronous replication) inserts
>> > its commit record, and then another transaction with
>> > synchronous_commit=off comes along and inserts its commit record, the
>> > second transaction will have to block until the first transaction is
>> > done waiting.
>>
>> What is the current behavior when the synchronous replication fails (say
>> the slave breaks down) - will the transaction be rolled back at some
>> point or will it wait indefinitely , that is until a new slave is
>> installed ?
>
> More importantly, if the master crashes after the commit is written to
> WAL, will the transaction be rolled back after recovery based on the
> fact that no confirmation from synchronous slave is received ?
No. You can't roll back a transaction once it's committed - ever.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
