One minor side note… Is it weird for xmin/xmax to go backwards in a hot row
chain?
lp | t_ctid | lp_off | t_infomask | t_infomask2 | t_xmin | t_xmax
----+--------+--------+------------+-------------+--------+--------
1 | (0,1) | 8152 | 2818 | 3 | 36957 | 0
2 | | 5 | | | |
3 | | 0 | | | |
4 | | 0 | | | |
5 | (0,6) | 8112 | 9986 | 49155 | 36962 | 36963
6 | (0,7) | 8072 | 9986 | 49155 | 36963 | 36961
7 | (0,7) | 8032 | 11010 | 32771 | 36961 | 0
(7 rows)
On 10/3/17, 6:20 PM, "Peter Geoghegan" <p...@bowt.ie> wrote:
On Tue, Oct 3, 2017 at 6:09 PM, Wood, Dan <hexp...@amazon.com> wrote:
> I’ve just started looking at this again after a few weeks break.
> if (TransactionIdIsValid(priorXmax) &&
> !TransactionIdEquals(priorXmax,
HeapTupleHeaderGetXmin(htup)))
> break;
> We need to understand why these TXID equal checks exist. Can we
differentiate the cases they are protecting against with the two exceptions
I’ve found?
I haven't read your remarks here in full, since I'm about to stop
working for the day, but I will point out that
src/backend/access/heap/README.HOT says a fair amount about this,
under "Abort Cases".
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
