Re: cheaper snapshots

On Thu, Jul 28, 2011 at 3:32 PM, Hannu Krosing <hannu@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