BUG #8273: Assertion failure in 9.3 beta2 with serializable and savepoints

The following bug has been logged on the website:

Bug reference:      8273
Logged by:          David Leverton
Email address:      levertond@googlemail.com
PostgreSQL version: Unsupported/Unknown
Operating system:   RHEL 5 x86_64
Description:

The following test case causes a backend assertion failure in 9.3 beta2:


START TRANSACTION ISOLATION LEVEL SERIALIZABLE;
CREATE TABLE testing(
  x INTEGER PRIMARY KEY
);
INSERT INTO testing VALUES(1);
SELECT * FROM testing WHERE x = 1 FOR UPDATE;
SAVEPOINT test;
UPDATE testing SET x = 2 WHERE x = 1;
ROLLBACK TO test;
UPDATE testing SET x = 3 WHERE x = 1;
ROLLBACK;


TRAP: FailedAssertion("!(((xid) != ((TransactionId) 0)))", File:
"predicate.c", Line: 3936)


Postgres was installed using the RPMs from http://yum.pgrpms.org/, and is
using a near-default configuration (changes to port number, data directory
and pg_hba.conf, and some roles created, but nothing likely to influence
this bug).


The full backtrace is as follows:


#0  0x0000003d66a30265 in raise () from /lib64/libc.so.6
#1  0x0000003d66a31d10 in abort () from /lib64/libc.so.6
#2  0x000000000074af8d in ExceptionalCondition (
    conditionName=<value optimized out>, errorType=<value optimized out>,
    fileName=<value optimized out>, lineNumber=<value optimized out>)
    at assert.c:54
#3  0x00000000006784bf in CheckForSerializableConflictOut (visible=1
'\001',
    relation=<value optimized out>, tuple=<value optimized out>,
    buffer=<value optimized out>, snapshot=<value optimized out>)
    at predicate.c:3936
#4  0x000000000049208e in heap_hot_search_buffer (tid=0x2abfdac,
    relation=0x2ad4b49eba78, buffer=260, snapshot=0x29cb3b0,
    heapTuple=0x2abfda8, all_dead=0x7fff510be26f "\001X\375\253\002",
    first_call=1 '\001') at heapam.c:1730
#5  0x000000000049ad1a in index_fetch_heap (scan=0x2abfd58) at
indexam.c:529
#6  0x000000000049afb3 in index_getnext (scan=0x2abfd58,
    direction=ForwardScanDirection) at indexam.c:612
#7  0x00000000005adafb in IndexNext (node=0x2abe9d0) at nodeIndexscan.c:78
#8  0x00000000005a1cf8 in ExecScanFetch (node=0x2abe9d0,
    accessMtd=0x5adab0 <IndexNext>, recheckMtd=0x5ada60 <IndexRecheck>)
    at execScan.c:82
#9  ExecScan (node=0x2abe9d0, accessMtd=0x5adab0 <IndexNext>,
    recheckMtd=0x5ada60 <IndexRecheck>) at execScan.c:167
#10 0x000000000059a94e in ExecProcNode (node=0x2abe9d0) at
execProcnode.c:404
#11 0x00000000005b1253 in ExecModifyTable (node=0x2abe6c0)
    at nodeModifyTable.c:918
#12 0x000000000059a90c in ExecProcNode (node=0x2abe6c0) at
execProcnode.c:377
#13 0x0000000000599b4d in ExecutePlan (queryDesc=0x2a98408,
direction=12114,
    count=0) at execMain.c:1470
#14 standard_ExecutorRun (queryDesc=0x2a98408, direction=12114, count=0)
    at execMain.c:306
#15 0x0000000000683e5f in ProcessQuery (plan=0x2ab32c0,
    sourceText=0x2a67128 "UPDATE testing SET x = 3 WHERE x = 1;",
    params=<value optimized out>, dest=0x2ab33b8,
    completionTag=0x7fff510be700 "") at pquery.c:185
#16 0x00000000006840d7 in PortalRunMulti (portal=0x29d12a8,
    isTopLevel=<value optimized out>, dest=0x2ab33b8, altdest=0x2ab33b8,
    completionTag=0x7fff510be700 "") at pquery.c:1279
#17 0x0000000000684cf2 in PortalRun (portal=0x29d12a8,
    count=9223372036854775807, isTopLevel=1 '\001', dest=0x2ab33b8,
    altdest=0x2ab33b8, completionTag=0x7fff510be700 "") at pquery.c:816
#18 0x000000000068105d in exec_simple_query (
    query_string=0x2a67128 "UPDATE testing SET x = 3 WHERE x = 1;")
    at postgres.c:1048
#19 0x000000000068255e in PostgresMain (argc=<value optimized out>,
    argv=<value optimized out>, dbname=0x29d6088 "postgres",
    username=<value optimized out>) at postgres.c:3985
#20 0x00000000006355b6 in ServerLoop () at postmaster.c:3987
#21 0x0000000000638a77 in PostmasterMain (argc=5, argv=0x29b0b80)
    at postmaster.c:1246
#22 0x00000000005ce293 in main (argc=5, argv=<value optimized out>)
    at main.c:196