Re: Synchronous commit not... synchronous?

On Fri, Nov 2, 2012 at 11:41 AM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
> On Fri, Nov 2, 2012 at 10:31 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On 2 November 2012 16:27, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>>> It would be. But you are not cancelling the commit, you are
>>> *attempting* to cancel the commit. The message you receive explains
>>> to what extend your attempt succeeded.
>>
>> That is correct.
>>
>> It is possible to cancel the COMMIT, but only until it happens.
>>
>> If people want full two phase commit, that option exists also.
>
> I see why it is implemented this way, but it's also still pretty
> unsatisfying because it means that with cancellation requests clients
> are in theory able to commit an unlimited number of transactions,
> synchronous commit or no.

What evil does this allow the client to perpetrate?

> It's probably close enough for most purposes, but what would you think
> about a "2PC-ish" mode at the physical (rather than logical/PREPARE
> TRANSACTION) level, whereby the master would insist that its standbys
> have more data written (or at least received...or at least sent) than
> it has guaranteed flushed to its own xlog at any point?

Then if they interrupt the commit, the remote has it permanently but
the local does not. That would be corruption.

What the "DETAIL" doesn't make clear about the current system is that
the commit *will* be replicated to the standby *eventually*, unless
the master burns down first. In particular, if any commit after this
one makes it to the standby, then the interrupted one is guaranteed to
have made it as well.

> This would be a nice invariant to have when dealing with a large
> number of systems, allowing for the catching of some tricky bugs, that
> standbys are always greater-than-or-equal-to the master's XLogPos.

Could you elaborate on that?

Cheers,

Jeff