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