Re: Proposal for CSN based snapshots

On 08/10/2016 04:34 PM, Alexander Korotkov wrote:
> On Tue, Aug 9, 2016 at 3:16 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
>> I switched to using a separate counter for CSNs. CSN is no longer the same
>> as the commit WAL record's LSN. While I liked the conceptual simplicity of
>> CSN == LSN a lot, and the fact that the standby would see the same commit
>> order as master, I couldn't figure out how to make async commits to work.
>
> I didn't get async commits problem at first glance.  AFAICS, the difference
> between sync commit and async is only that async commit doesn't wait WAL
> log to flush.  But async commit still receives LSN.
> Could you describe it in more details?

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.

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.

Perhaps you could make an exception for async commits, so that the CSN 
of an async commit is not the commit record's LSN, but the current WAL 
flush position, so that it becomes visible to others immediately. But 
then, how do you distinguish two async transactions that commit roughly 
at the same time, so that the flush position at time of commit is the 
same for both? And now you've given up on the CSN == LSN property, for 
async commits, anyway.

- Heikki