On Mon, Oct 30, 2017 at 5:48 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Thu, Oct 26, 2017 at 7:41 PM, Masahiko Sawada <sawada.m...@gmail.com> > wrote: >> >> Because I don't want to break the current user semantics. that is, >> currently it's guaranteed that the subsequent reads can see the >> committed result of previous writes even if the previous transactions >> were distributed transactions. And it's ensured by writer side. If we >> can make the reader side ensure it, the backend process don't need to >> wait for the resolver process. >> >> The waiting backend process are released by resolver process after the >> resolver process tried to resolve foreign transactions. Even if >> resolver process failed to either connect to foreign server or to >> resolve foreign transaction the backend process will be released and >> the foreign transactions are leaved as dangling transaction in that >> case, which are processed later. Also if resolver process takes a long >> time to resolve foreign transactions for whatever reason the user can >> cancel it by Ctl-c anytime. >> > > So, there's no guarantee that the next command issued from the > connection *will* see the committed data, since the foreign > transaction might not have committed because of a network glitch > (say). If we go this route of making backends wait for resolver to > resolve the foreign transaction, we will have add complexity to make > sure that the waiting backends are woken up in problematic events like > crash of the resolver process OR if the resolver process hangs in a > connection to a foreign server etc. I am not sure that the complexity > is worth the half-guarantee. >
Hmm, maybe I was wrong. I now think that the waiting backends can be woken up only in following cases; - The resolver process succeeded to resolve all foreign transactions. - The user did the cancel (e.g. ctl-c). - The resolver process failed to resolve foreign transaction for a reason of there is no such prepared transaction on foreign server. In other cases the resolver process should not release the waiters. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers