From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Ants Aasma <ants(dot)aasma(at)eesti(dot)ee> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: cheaper snapshots |
Date: | 2011-07-29 00:15:06 |
Message-ID: | CA+TgmoaykSnfGERXRe-+2+iqZj=H+fQ+L1f=6hKpX=5eAEhiuA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 28, 2011 at 8:12 PM, Ants Aasma <ants(dot)aasma(at)eesti(dot)ee> wrote:
> On Fri, Jul 29, 2011 at 2:20 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Well, again, there are three levels:
>>
>> (A) synchronous_commit=off. No waiting!
>> (B) synchronous_commit=local transactions, and synchronous_commit=on
>> transactions when sync rep is not in use. Wait for xlog flush.
>> (C) synchronous_commit=on transactions when sync rep IS in use. Wait
>> for xlog flush and replication.
> ...
>> So basically, you can't be more asynchronous than the guy in front of
>> you.
>
> (A) still gives a guarantee - transactions that begin after the commit
> returns see
> the commited transaction. A weaker variant would say that if the commit
> returns, and the server doesn't crash in the meantime, the commit would at
> some point become visible. Maybe even that transactions that begin after the
> commit returns become visible after that commit.
Yeah, you could do that. But that's such a weak guarantee that I'm
not sure it has much practical utility.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2011-07-29 03:05:15 | Re: sinval synchronization considered harmful |
Previous Message | Robert Haas | 2011-07-29 00:14:53 | Re: cheaper snapshots |