On Thu, Jul 28, 2011 at 4:12 PM, Kevin Grittner
<kevin.gritt...@wicourts.gov> wrote:
> Hannu Krosing <ha...@2ndquadrant.com> wrote:
>> 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.
> Possibly. That combined with building snapshots based on the order
> of WAL entries of commit records certainly has several appealing
> aspects.  It is hard to get over the fact that you lose an existing
> guarantee, though: right now, if you have one synchronous replica,
> you can never see a transaction's work on the master and then *not*
> see it on the slave -- the slave always has first visibility.  I
> don't see how such a guarantee can exist in *either* direction with
> the semantics you describe.  After seeing a transaction's work on
> one system it would always be unknown whether it was visible on the
> other.  There are situations where that is OK as long as each copy
> has a sane order of visibility, but there are situations where
> losing that guarantee might matter.
> On the bright side, it means that transactions would become visible
> on the replica in the same order as on the master, and that blocking
> would be reduced.

Having transactions become visible in the same order on the master and
the standby is very appealing, but I'm pretty well convinced that
allowing commits to become visible before they've been durably
committed is throwing the "D" an ACID out the window.  If
synchronous_commit is off, sure, but otherwise...


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to