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" <pg@bowt.ie> wrote:
On Tue, Oct 3, 2017 at 6:09 PM, Wood, Dan <hexpert@amazon.com> wrote: > I’ve just started looking at this again
aftera few weeks break. > if (TransactionIdIsValid(priorXmax) && >
!TransactionIdEquals(priorXmax,HeapTupleHeaderGetXmin(htup))) > break; > We need to
understandwhy these TXID equal checks exist. Can we differentiate the cases they are protecting against with the two
exceptionsI’ve found? I haven't read your remarks here in full, since I'm about to stop working for the day, but
Iwill 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