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