BUG #10533: 9.4 beta1 assertion failure in autovacuum process

The following bug has been logged on the website:

Bug reference:      10533
Logged by:          David Leverton
Email address:      levertond@googlemail.com
PostgreSQL version: 9.4beta1
Operating system:   RHEL 5 x86_64
Description:

Our application's test suite triggers an assertion failure in an autovacuum
process under 9.4 beta1.  I wasn't able to reduce it to a nice test case,
but I hope the backtrace illustrates the problem:

#0  0x00000032bae30265 in raise () from /lib64/libc.so.6
#1  0x00000032bae31d10 in abort () from /lib64/libc.so.6
#2  0x000000000078b69d in ExceptionalCondition (conditionName=<value
optimized out>, errorType=<value optimized out>,
    fileName=<value optimized out>, lineNumber=<value optimized out>) at
assert.c:54
#3  0x00000000007ad6e2 in palloc (size=16) at mcxt.c:670
#4  0x00000000004d3592 in GetMultiXactIdMembers (multi=75092,
members=0x7fff915f9468, allow_old=0 '\000') at multixact.c:1242
#5  0x0000000000495c9c in MultiXactIdGetUpdateXid (xmax=17061,
t_infomask=<value optimized out>) at heapam.c:6059
#6  0x00000000007ba93c in HeapTupleHeaderIsOnlyLocked (tuple=0x42a5) at
tqual.c:1539
#7  0x00000000007baf2c in HeapTupleSatisfiesVacuum (htup=<value optimized
out>, OldestXmin=67407, buffer=347) at tqual.c:1174
#8  0x00000000005a96eb in heap_page_is_all_visible (onerel=0x2b1b020f3f58,
blkno=86, buffer=347, tupindex=339, vacrelstats=0x1cfe3148,
    vmbuffer=0x7fff915fa65c) at vacuumlazy.c:1788
#9  lazy_vacuum_page (onerel=0x2b1b020f3f58, blkno=86, buffer=347,
tupindex=339, vacrelstats=0x1cfe3148, vmbuffer=0x7fff915fa65c)
    at vacuumlazy.c:1220
#10 0x00000000005a9acb in lazy_vacuum_heap (onerel=0x2b1b020f3f58,
vacrelstats=0x1cfe3148) at vacuumlazy.c:1152
#11 0x00000000005ab393 in lazy_scan_heap (onerel=0x2b1b020f3f58,
vacstmt=<value optimized out>, bstrategy=<value optimized out>)
    at vacuumlazy.c:1080
#12 lazy_vacuum_rel (onerel=0x2b1b020f3f58, vacstmt=<value optimized out>,
bstrategy=<value optimized out>) at vacuumlazy.c:239
#13 0x00000000005a8b35 in vacuum_rel (relid=18303, vacstmt=0x7fff915fae20,
do_toast=<value optimized out>, for_wraparound=0 '\000') at vacuum.c:1202
#14 0x00000000005a8f89 in vacuum (vacstmt=0x7fff915fae20, relid=<value
optimized out>, do_toast=0 '\000', bstrategy=<value optimized out>,
    for_wraparound=0 '\000', isTopLevel=<value optimized out>) at
vacuum.c:234
#15 0x0000000000646d14 in do_autovacuum () at autovacuum.c:2796
#16 0x00000000006475bb in AutoVacWorkerMain (argc=<value optimized out>,
argv=<value optimized out>) at autovacuum.c:1678
#17 0x0000000000647669 in StartAutoVacWorker () at autovacuum.c:1463
#18 0x0000000000655741 in StartAutovacuumWorker (postgres_signal_arg=<value
optimized out>) at postmaster.c:5188
#19 sigusr1_handler (postgres_signal_arg=<value optimized out>) at
postmaster.c:4842
#20 <signal handler called>
#21 0x00000032baecd323 in __select_nocancel () from /lib64/libc.so.6
#22 0x000000000065286f in ServerLoop () at postmaster.c:1530
#23 0x00000000006566e2 in PostmasterMain (argc=3, argv=0x1cf79b80) at
postmaster.c:1223
#24 0x00000000005e6f4c in main (argc=3, argv=0x1a) at main.c:225

I did look at recent commits in the area and it seems possible that 621a99a
might have fixed the problem, if I'm understanding things correctly (it
seems it now only calls GetMultiXactIdMembers when it's looking at a row
inserted by the current transaction, which presumably wouldn't happen for a
vacuum), but I'm not in a convenient situation to test a git build at the
moment, and even if I did and it turned out not to crash anymore, I wouldn't
be certain that it was fixed rather than just masked under those particular
circumstances.  Apologies if this report turns out to be noise.

Postgres was installed using the RPMs from http://yum.pgrpms.org/, with no
interesting configuration changes (only listen_addresses and pg_hba.conf).