From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <hlinnaka@iki.fi>
cc: Alexander Korotkov <a.korotkov@postgrespro.ru>,
        Simon Riggs <simon@2ndquadrant.com>,
        Robert Haas <robertmhaas@gmail.com>,
        Dilip Kumar <dilipbalaut@gmail.com>, Jeff Davis <pgsql@j-davis.com>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>,
        Alvaro Herrera <alvherre@2ndquadrant.com>, Greg Stark <stark@mit.edu>,
        Andres Freund <andres@2ndquadrant.com>,
        Rajeev rastogi <rajeev.rastogi@huawei.com>,
        Markus Wanner <markus@bluegap.ch>, Ants Aasma <ants@cybertec.at>,
        Bruce Momjian <bruce@momjian.us>,
 obartunov <obartunov@postgrespro.ru>,
        Teodor Sigaev <teodor@postgrespro.ru>
Subject: Re: Proposal for CSN based snapshots
In-reply-to: <a7e33ad4-cf1e-2e7c-6752-de91302292dc@iki.fi>
References: <51B6C97B.1070000@bluegap.ch>
 <20140515213714.GB7857@eldon.alvh.no-ip.org> <53889CCB.7030005@vmware.com>
 <20140530152721.GC30516@awork2.anarazel.de> <5388D02D.6040305@vmware.com>
 <CA+TgmoZ4cP_1Pavwn+VX74_ksDhHf-whO5FFR1j+NdZqONu8MA@mail.gmail.com>
 <CAM-w4HMG-YeTfWc3r_excej3Kd04q4zDDXR0hxShVbij211ABA@mail.gmail.com>
 <539AD153.9000004@vmware.com> <1409043789.2335.330.camel@jeff-desktop>
 <53FC6545.7000501@vmware.com> <1409116988.2335.463.camel@jeff-desktop>
 <53FD7D65.9040602@vmware.com> <53FD7DCC.5020005@vmware.com>
 <CAPpHfdsCUb4qBUHzfqNsUYALC_LEpHD9qB-ozvS_8esv1edCTw@mail.gmail.com>
 <CANP8+jLAe3Smtq3FF49DMvuxtfoRQcCPQn28GEKuwAb2J41XCA@mail.gmail.com>
 <CA+Tgmob1DmDsvc7iyd0SY5j4SFdesDwoef36bxG1pE_s1JQXOQ@mail.gmail.com>
 <CANP8+jLyhL92eJi7RVX_yvbKjxm9=OBKcmNnodaYmeE+o2i1+Q@mail.gmail.com>
 <CAPpHfdv7BMwGv=OfUg3S-jGVFKqHi79pR_ZK1Wsk-13oZ+cy5g@mail.gmail.com>
 <69041c5a-ec60-3c54-49d0-5df071b27f52@iki.fi>
 <CAPpHfdsGqb1EtmWo7wJZz=TXaBM_xwAEhfr-nNG8+c57Tm_cbQ@mail.gmail.com!
 > <a7e33ad4-cf1e-2e7c-6752-de91302292dc@iki.fi>
Comments: In-reply-to Heikki Linnakangas <hlinnaka@iki.fi>
	message dated "Wed, 10 Aug 2016 16:57:35 +0300"
Date: Wed, 10 Aug 2016 10:09:07 -0400
Message-ID: <5596.1470838147@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Heikki Linnakangas <hlinnaka@iki.fi> writes:
> Imagine that you have a stream of normal, synchronous, commits. They get 
> assigned LSNs: 1, 2, 3, 4. They become visible to other transactions in 
> that order.

> The way I described this scheme in the first emails on this thread, was 
> to use the current WAL insertion position as the snapshot. That's not 
> correct, though: you have to use the current WAL *flush* position as the 
> snapshot. Otherwise you would see the results of a transaction that 
> hasn't been flushed to disk yet, i.e. which might still get lost, if you 
> pull the power plug before the flush happens. So you have to use the 
> last flush position as the snapshot.

Uh, what?  That's not the semantics we have today, and I don't see why
it's necessary or a good idea.  Once the commit is in the WAL stream,
any action taken on the basis of seeing the commit must be later in
the WAL stream.  So what's the problem?

> Now, if you do an asynchronous commit, the effects of that should become 
> visible immediately, without waiting for the next flush. You can't do 
> that, if its CSN == LSN.

This distinction is completely arbitrary, and unlike the way it works now.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers