On Mon, Nov 5, 2012 at 2:59 PM, Daniel Farina <dan...@heroku.com> wrote: > On Sun, Nov 4, 2012 at 6:00 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Sat, Nov 3, 2012 at 5:44 PM, Florian Weimer <f...@deneb.enyo.de> wrote: >>> * Daniel Farina: >>>> The idea of canceling a COMMIT statement causing a COMMIT seems pretty >>>> strange to me. >>> >>> Canceling commits is inherently racy, so I'm not sure if this behavior >>> so strange after all. >> >> Yeah. You can't make the local fsync() and the remote fsync() happen >> at exactly the same moment in time. No implementation can do that, >> anywhere, ever. Our implementation happens to require the local >> fsync() to always be done first. > > I don't think there is a (unachievable) requirement of simultaneous > flush, only that two machines have flushed (or met whatever durability > criteria) strictly more than the position of the commit in question. > This mean some changes are written to some place once, but > acknowledging commit requires proof of two-safety.
Right, but what you're complaining about is that you can't cancel the transaction after beginning to make it 2-safe. > I can see how in some corner cases this might cause orphaning of > synchronous standbys that write, but cannot acknowledge. > > If the point of synchronous commit is to reach exact two-safety by > waiting a while for other agents to process data, it would seem that > the current model could use some less-invasive tweaking, as-is one can > succeed in an unbounded number of commits in a degenerate case. Well, feel free to make a suggestion. We could have a mode where a commit, once initiated, is not user-cancellable, but that doesn't seem like a usability improvement to me. That just forces somebody to bounce the server in a situation where it isn't necessary. The warning is not unclear about what has happened. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers