Re: BUG #6222: Segmentation fault on unlogged table

On Sun, Sep 25, 2011 at 9:16 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> When I made pgbench tables unlogged and ran pgbench, I encountered a
> segmentation fault. Here is the test case which reproduces a segmentation
> fault:
>
> $ pgbench -i
> $ pg_dump > pgbench.dump
> $ sed s/"CREATE TABLE"/"CREATE UNLOGGED TABLE"/g pgbench.dump >
> pgbench_unlogged.dump
> $ createdb test
> $ psql -f pgbench_unlogged.dump test
> $ pgbench -c2 -T60 -Mprepared

The first time I did this (on MacOS X), I got a bus error, just as you
did. But I followed the exact series of commands above, which I
believe would end up with the test running against the default
database (with regular tables), rather than the test database with
unlogged tables. The second time, it worked OK against the regular
tables, so I then tried it again against the unlogged tables (by
running the last command in the series again with "test" added to the
end) and it then crashed with the following backtrace:

#0 0x0000000101153560 in ?? ()
#1 0x00000001001540fe in ExecScan (node=0x7fff5fbfde4f,
accessMtd=0x100167150 <SeqNext>, recheckMtd=0x100166ef0 <SeqRecheck>)
at execScan.c:195
#2 0x000000010014bcb2 in ExecProcNode (node=0x101151f30) at execProcnode.c:393
#3 0x0000000100164691 in ExecModifyTable (node=0x101151c20) at
nodeModifyTable.c:766
#4 0x000000010014bcf2 in ExecProcNode (node=0x101151c20) at execProcnode.c:370
#5 0x000000010014a10e in ExecutePlan [inlined] () at
/Users/rhaas/pgsql/src/backend/executor/execMain.c:1438
#6 0x000000010014a10e in standard_ExecutorRun (queryDesc=0x10113f388,
direction=ForwardScanDirection, count=0) at execMain.c:312
#7 0x000000010023f714 in ProcessQuery (plan=0x101140e98,
sourceText=0x10113f238 "UPDATE pgbench_branches SET bbalance =
bbalance + $1 WHERE bid = $2;", params=<value temporarily unavailable,
due to optimizations>, dest=0x100520420, completionTag=0x7fff5fbfe450
"") at pquery.c:185
#8 0x000000010023fe77 in PortalRunMulti (portal=0x10113d238,
isTopLevel=<value temporarily unavailable, due to optimizations>,
dest=0x100520420, altdest=0x100520420, completionTag=0x7fff5fbfe450
"") at pquery.c:1274
#9 0x0000000100240888 in PortalRun (portal=0x10113d238,
count=9223372036854775807, isTopLevel=<value temporarily unavailable,
due to optimizations>, dest=0x101055a50, altdest=0x101055a50,
completionTag=0x7fff5fbfe450 "") at pquery.c:8&
#11 0x00000001001ee7ec in ServerLoop () at postmaster.c:3512
#12 0x00000001001ef6d7 in PostmasterMain (argc=1, argv=0x100c08c40) at
postmaster.c:1093
#13 0x00000001001824b5 in main (argc=1, argv=0x100c08c40) at main.c:199

Unfortunately, this is thoroughly unhelpful, because the top of the
stack has apparently been clobbered, and I can't see where inside
ExecQual the crash is happening.

(gdb) fr 1
#1 0x00000001001540fe in ExecScan (node=0x7fff5fbfde4f,
accessMtd=0x100167150 <SeqNext>, recheckMtd=0x100166ef0 <SeqRecheck>)
at execScan.c:195
195 if (!qual || ExecQual(qual, econtext, false))

The whole thing is a bit mysterious because ExecQual() doesn't really
do much that seems like it could generate an invalid memory reference.

I'll poke at this some more...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company