On Thu, 2011-07-28 at 16:20 -0400, Robert Haas wrote: > 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.
so in case of stuck slave the syncrep transcation is committed after crash, but is not committed before the crash happens ? ow will the replay process get stuc gaian during recovery ? > > -- > 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
