Re: Exposing the Xact commit order to the user

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>,<JanWieck(at)yahoo(dot)com>
Subject: Re: Exposing the Xact commit order to the user
Date: 2010-05-25 20:17:16
Message-ID: 4BFBE9FC0200002500031A95@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> maybe we should get serializable working and committed on one
> node first and then worry about how to distribute it. I think
> there might be other approaches to this problem

Well, I've got two or three other ideas on how we can manage this
for HS, but since I now realize that I've totally misunderstood the
main use case for this (which is to support trigger-based
replication), I'd like to be clear on something before letting it
drop. The big question is, do such replicas need to support
serializable access to the data modified by serializable
transactions in the source database? That is, is there a need for
such replicas to only see states which are possible in some serial
order of execution of serializable transactions on the source
database? Or to phrase the same question a third way, should there
be a way to run queries on such replicas with confidence that what
is viewed is consistent with user-defined constraints and business
rules?

If not, there's no intersection between this feature and SSI. If
there is, I think we should think through at least a general
strategy sooner, rather than later.

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Graf 2010-05-25 20:40:27 Re: Hiding data in postgresql
Previous Message Simon Riggs 2010-05-25 20:16:30 Re: Synchronization levels in SR