* Stephen Frost (sfr...@snowman.net) wrote: > I have the pre-upgrade database and can upgrade/rollback/etc that pretty > easily. Note that the table contents weren't changed during the > upgrade, of course, and so the 9.2.6 instance has HEAP_XMAX_IS_MULTI set > while t_xmax is 6849409 for the tuple in question- even though > pg_controldata reports NextMultiXactId as 1601462 (and it seems very > unlikely that there's been a wraparound on that in this database..).
Further review leads me to notice that both HEAP_XMAX_IS_MULTI and HEAP_XMAX_INVALID are set: t_infomask | 6528 6528 decimal -> 0x1980 0001 1001 1000 0000 Which gives us: 0000 0000 1000 0000 - HEAP_XMAX_LOCK_ONLY 0000 0001 0000 0000 - HEAP_XMIN_COMMITTED 0000 1000 0000 0000 - HEAP_XMAX_INVALID 0001 0000 0000 0000 - HEAP_XMAX_IS_MULTI Which shows that both HEAP_XMAX_INVALID and HEAP_XMAX_IS_MULTI are set. Of some interest is that HEAP_XMAX_LOCK_ONLY is also set.. > Perhaps something screwed up xmax/HEAP_XMAX_IS_MULTI under 9.2 and the > 9.3 instance now detects that something is wrong? Or is this a case > which was previously allowed and it's just in 9.3 that we don't like it? The 'improve concurrency of FK locking' patch included a change to UpdateXmaxHintBits(): - * [...] Hence callers should look - * only at XMAX_INVALID. ... + * Hence callers should look only at XMAX_INVALID. + * + * Note this is not allowed for tuples whose xmax is a multixact. [...] + Assert(!(tuple->t_infomask & HEAP_XMAX_IS_MULTI)); What isn't clear to me is if this restriction was supposed to always be there and something pre-9.3 screwed this up, or if this is a *new* restriction on what's allowed, in which case it's an on-disk format change that needs to be accounted for. One other thing to mention is that this system was originally a 9.0 system and the last update to this tuple that we believe happened was when it was on 9.0, prior to the 9.2 upgrade (which happened about a year ago), so it's possible the issue is from the 9.0 era. Thanks, Stephen
Description: Digital signature