Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updatedtuple

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