On Mon, Nov 27, 2017 at 4:35 PM Masahiko Sawada <sawada.m...@gmail.com> wrote:
> What I'd like to guarantee is that the subsequent read can see the > committed result of previous writes if the transaction involving > multiple foreign servers is committed without cancellation by user. In > other words, the backend should not be waken up and the resolver > should continue to resolve at certain intervals even if the resolver > fails to connect to the foreign server or fails to resolve it. This is > similar to what synchronous replication guaranteed today. Keeping this > semantics is very important for users. Note that the reading a > consistent result by concurrent reads is a separated problem. > > The read result including foreign servers can be inconsistent if the > such transaction is cancelled or the coordinator server crashes during > two-phase commit processing. That is, if there is in-doubt transaction > the read result can be inconsistent, even for subsequent reads. But I > think this behaviour can be accepted by users. For the resolution of > in-doubt transactions, the resolver process will try to resolve such > transactions after the coordinator server recovered. On the other > hand, for the reading a consistent result on such situation by > subsequent reads, for example, we can disallow backends to inquiry SQL > to the foreign server if a foreign transaction of the foreign server > is remained. > > For the concurrent reads, the reading an inconsistent result can be > happen even without in-doubt transaction because we can read data on a > foreign server between PREPARE and COMMIT PREPARED while other foreign > servers have committed. I think we should deal with this problem by > other feature on reader side, for example, atomic visibility. If we > have atomic visibility feature, we also can solve the above problem. +1 to all of that. ...Robert > > -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
