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 ?
> Or will the sync rep transaction commit when archive_command returns
> true after copying the WAL segment containing this commit ?
>
> > 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 ?
>
--
-------
Hannu Krosing
PostgreSQL Infinite Scalability and Performance Consultant
PG Admin Book: http://www.2ndQuadrant.com/books/
