Re: Synchronous commit not... synchronous?

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.

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?

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.

--
fdr