On Thu, Jul 28, 2011 at 3:40 PM, Hannu Krosing <ha...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
