On 2013-12-03 09:16:18 -0500, Noah Misch wrote:
> > > The test spec additionally
> > > covers a (probably-related) assertion failure, new in 9.3.2.
> >
> > Too bad it's too late to do anthing about it for 9.3.2. :(. At least the
> > last seems actually unrelated, I am not sure why it's 9.3.2
> > only. Alvaro, are you looking?
>
> (For clarity, the other problem demonstrated by the test spec is also a 9.3.2
> regression.)
The backtrace for the Assert() you found is:
#4 0x00000000004f1da5 in CreateMultiXactId (nmembers=2, members=0x1ce17d8) at
/home/andres/src/postgresql/src/backend/access/transam/multixact.c:708
#5 0x00000000004f1aeb in MultiXactIdExpand (multi=6241831, xid=6019366, status=MultiXactStatusUpdate) at
/home/andres/src/postgresql/src/backend/access/transam/multixact.c:462
#6 0x00000000004a5d8e in compute_new_xmax_infomask (xmax=6241831, old_infomask=4416, old_infomask2=16386,
add_to_xmax=6019366, mode=LockTupleExclusive, is_update=1 '\001', result_xmax=0x7fffca02a700,
result_infomask=0x7fffca02a6fe, result_infomask2=0x7fffca02a6fc) at
/home/andres/src/postgresql/src/backend/access/heap/heapam.c:4651
#7 0x00000000004a2d27 in heap_update (relation=0x7f9fc45cc828, otid=0x7fffca02a8d0, newtup=0x1ce1740, cid=0,
crosscheck=0x0, wait=1 '\001', hufd=0x7fffca02a850, lockmode=0x7fffca02a82c) at
/home/andres/src/postgresql/src/backend/access/heap/heapam.c:3304
#8 0x0000000000646f04 in ExecUpdate (tupleid=0x7fffca02a8d0, oldtuple=0x0, slot=0x1ce12c0, planSlot=0x1ce0740,
epqstate=0x1ce0120, estate=0x1cdfe98, canSetTag=1 '\001') at
/home/andres/src/postgresql/src/backend/executor/nodeModifyTable.c:690
So imo it isn't really a new problem, it existed all along :/. We only
don't hit it in your terstcase before because we spuriously thought that
a tuple was in-progress if *any* member of the old multi were still
running in some cases instead of just the updater. But I am pretty sure
it can also reproduced in 9.3.1.
Imo the MultiXactIdSetOldestMember() call in heap_update() needs to be
moved outside of the if (satisfies_key). Everything else is vastly more
complex.
Alvaro, correct?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services