On Thu, Jul 28, 2011 at 3:32 PM, Hannu Krosing <ha...@2ndquadrant.com> 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 ?
It will wait forever, unless you shut down the database or hit ^C. >> We can't make either transaction visible without making >> both visible, and we certainly can't acknowledge the second >> transaction to the client until we've made it visible. I'm not going >> to say that's so horrible we shouldn't even consider it, but it >> doesn't seem great, either. > > Maybe this is why other databases don't offer per backend async commit ? Yeah, possibly. -- 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
