From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Greg Stark <stark@mit.edu>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Andres Freund <andres@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Rajeev rastogi <rajeev.rastogi@huawei.com>
Cc: Ants Aasma <ants@cybertec.at>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Markus Wanner <markus@bluegap.ch>
Subject: Re: Proposal for CSN based snapshots
Date: Fri, 30 May 2014 18:14:43 +0300
Message-ID: <5388A063.5000209@vmware.com> (raw)
In-Reply-To: <CAM-w4HNd7scGsvX_e+sxbPB1Y33MHp9D=go69Y4V37KhjE7heg@mail.gmail.com>
References: <51B1CB35.4050406@bluegap.ch>
<CA+CSw_uSzXidemci-nU5fJY-qXD0DE0ZWz-j1ASTT_ffBjXo9Q@mail.gmail.com>
<51B6C97B.1070000@bluegap.ch>
<BF2827DCCE55594C8D7A8F7FFD3AB7713DDBC758@SZXEML508-MBX.china.huawei.com>
<5370D323.1070606@vmware.com>
<20140512144112.GB9619@awork2.anarazel.de>
<5370E267.2020904@vmware.com>
<20140515183436.GD25053@momjian.us>
<CA+TgmoYiqga4KWz_1=O8D6ivmTAJfY=-fxO6Nk+D-o3M0M60=Q@mail.gmail.com>
<20140515200632.GB16014@awork2.anarazel.de>
<20140515213714.GB7857@eldon.alvh.no-ip.org>
<53889CCB.7030005@vmware.com>
<CAM-w4HNd7scGsvX_e+sxbPB1Y33MHp9D=go69Y4V37KhjE7heg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 05/30/2014 06:09 PM, Greg Stark wrote:
> On Fri, May 30, 2014 at 3:59 PM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>> If transaction A commits synchronously with commit LSN 1, and transaction B
>> commits asynchronously with commit LSN 2, B cannot become visible before A.
>> And we cannot acknowledge B as committed to the client until it's visible to
>> other transactions. That means that B will have to wait for A's commit
>> record to be flushed to disk, before it can return, even though it was an
>> asynchronous commit.
>
>
> I thought that's what happens now.
>
> What's more of a concern is synchronousl replication. We currently
> have a hack that makes transactions committed locally invisible to
> other transactions even though they've committed and synced to disk
> until the slave responds that it's received the transaction. (I think
> this is bogus personally, it just shifts the failure modes around. If
> we wanted to do it properly we would have to do two-phase commit.)
Yeah. To recap, the failure mode is that if the master crashes and
restarts, the transaction becomes visible in the master even though it
was never replicated.
> I guess it still works because we don't support having synchronous
> replication for just some transactions and not others. It would be
> nice to support that but I think it would mean making it work like
> local synchronous commit. It would only affect how long the commit
> blocks, not when other transactions see the committed data.
Actually, we do support that, see synchronous_commit=local.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: hlinnakangas@vmware.com, stark@mit.edu, alvherre@2ndquadrant.com, andres@2ndquadrant.com, robertmhaas@gmail.com, bruce@momjian.us, rajeev.rastogi@huawei.com, ants@cybertec.at, markus@bluegap.ch
Subject: Re: Proposal for CSN based snapshots
In-Reply-To: <5388A063.5000209@vmware.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox