Skip site navigation (1) Skip section navigation (2)

Re: cheaper snapshots

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Hannu Krosing <hannu(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: cheaper snapshots
Date: 2011-07-28 20:19:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Jul 28, 2011 at 3:32 PM, Hannu Krosing <hannu(at)2ndquadrant(dot)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
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-07-28 20:20:04
Subject: Re: cheaper snapshots
Previous:From: Kevin GrittnerDate: 2011-07-28 20:12:55
Subject: Re: cheaper snapshots

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group