On Thu, 2011-07-28 at 15:42 -0400, Tom Lane wrote:
> Hannu Krosing <hannu@2ndQuadrant.com> writes:
> > On Thu, 2011-07-28 at 14:27 -0400, Robert Haas wrote:
> >> We can't make either transaction visible without making
> >> both visible, and we certainly can't acknowledge the second
> >> transaction to the client until we've made it visible. I'm not going
> >> to say that's so horrible we shouldn't even consider it, but it
> >> doesn't seem great, either.
>
> > Maybe this is why other databases don't offer per backend async commit ?
>
> Yeah, I've always thought that feature wasn't as simple as it appeared.
> It got in only because it was claimed to be cost-free, and it's now
> obvious that it isn't.
I still think it is cost-free if you get the semantics of the COMMIT
contract right. (Of course it is not cost free as in not wasting
developers time in discussions ;) )
I'm still with you in claiming that transaction should be visible to
other backends as committed as soon as the WAL record is inserted.
the main thing to keep in mind is that getting back positive commit
confirmation really means (depending on various sync settings) that your
transaction is on stable storage.
BUT, _not_ getting back confirmation on commit does not quaranee that it
is not committed, just that you need to check. It may well be that it
was committed, written to stable storage _and_ also syncrepped but then
the confirnation did not come bac to you due to some network outage. or
your client computer crashed. or your child spilled black paint over the
monitor. or thousand other reasons.
async commit has the contract that you are ready to check a few latest
commits after crash.
but I still think that it is right semantics to make your commit visible
to others, even before you have gotten back the confirmation yourself.
-------
Hannu Krosing
PostgreSQL Infinite Scalability and Performance Consultant
PG Admin Book: http://www.2ndQuadrant.com/books/
