On 28.10.2019 19:40, Robert Haas wrote:
> 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.
Certainly I understand the difference between abort of transaction and
termination of backend.
I do not say that it is good solution. And definitely aborts can happen
for read-only transactions.
I just wanted to express one moment: transaction aborts are caused by
two reasons:
- expected programming errors: deadlocks, conversion errors, unique
constraint violation,...
- unexpected system errors: disk space exhaustion, out of memory, I/O
errors...
Usually at replica with read-only transactions we do not have to deal
with errors of first kind.
So transaction may be aborted, but such abort most likely means that
something is wrong with the system
and restart of backend is not so bad solution in this situation.
In any case, I do not insist on this "frozen XID" approach.
The only advantage of this approach is that it is very simple to
implement: correspondent patch contains just 80 lines of code
and actually it requires just 5 (five) one-line changes.
I didn't agree with your statement just because restart of backend makes
it not possible to observe any inconsistencies in the database.
> ...but given that we seem to agree on this point, perhaps it isn't
> necessary to argue about those things right now.
>
Ok.
I attached new patch for GTT with local (private) buffer and no replica
access.
It provides GTT for all built-in indexes
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
