(unnamed)
text/plain
> 2019年10月29日 上午12:40，Robert Haas <robertmhaas@gmail.com> 写道： > > On Mon, Oct 28, 2019 at 9:37 AM Konstantin Knizhnik > <k.knizhnik@postgrespro.ru> wrote: >> Sorry, but both statements are not true. > > Well, I think they are true. > >> I am not sure how vital is lack of aborts for transactions working with >> GTT at replica. >> Some people said that there is no sense in aborts of read-only >> transactions at replica (despite to the fact that them are saving >> intermediate results in GTT). >> Some people said something similar with your's "dead on arrival". >> But inconsistency is not possible: if such transaction is really >> aborted, then backend is terminated and nobody can see this inconsistency. > > Aborting the current transaction is a very different thing from > terminating the backend. > > Also, the idea that there is no sense in aborts of read-only > transactions on a replica seems totally wrong. Suppose that you insert > a row into the table and then you go to insert a row in each index, > but one of the index inserts fails - duplicate key, out of memory > error, I/O error, whatever. Now the table and the index are > inconsistent. Normally, we're protected against this by MVCC, but if > you use a solution that breaks MVCC by using the same XID for all > transactions, then it can happen. > >> Concerning second alternative: you can check yourself that it is not >> *extremely* complicated and invasive. >> I extracted changes which are related with handling transactions at >> replica and attached them to this mail. >> It is just 500 lines (including diff contexts). Certainly there are some >> limitation of this implementation: number of transactions working with >> GTT at replica is limited by 2^32 >> and since GTT tuples are not frozen, analog of GTT CLOG kept in memory >> is never truncated. > > I admit that this patch is not lengthy, but there remains the question > of whether it is correct. It's possible that the problem isn't as > complicated as I think it is, but I do think there are quite a number > of reasons why this patch wouldn't be considered acceptable... > >> I agree with it and think that implementation of GTT with private >> buffers and no replica access is good starting point. > > ...but given that we seem to agree on this point, perhaps it isn't > necessary to argue about those things right now. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company