Robert Haas <robertmhaas@gmail.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