On Mon, Oct 28, 2019 at 9:37 AM Konstantin Knizhnik <k.knizh...@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
