Thread: 7.3 backend crash
Hi. I just installed 7.3 on one of my development machines to start
getting ready for our migration to production. I was running some of
our regression tests and i noticed that the backend crashed. I didn't
run into this problem with any of the beta's or RC, but it's possible
that these particular tests weren't run.
Anyway, each query executes by itself, but if i execute both queries in
the same session (order doesn't matter), the back end crashes. Maybe it
has to do with temp tables? I've included a backtrace as a starting
point.
Please let me know what you need from me to help track this problem
down.
Thanks!
--brian
[postgres@tex postgres]$ gdb postgres
GNU gdb Red Hat Linux (5.2-2)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) set args -D /moby/pgsql-7.3 basement
(gdb) run
Starting program: /usr/pg-7.3/bin/postgres -D /moby/pgsql-7.3 basement
LOG: database system was interrupted at 2002-12-16 11:58:43 MST
LOG: checkpoint record is at 0/515D36D8
LOG: redo record is at 0/515D36D8; undo record is at 0/0; shutdown TRUE
LOG: next transaction id: 5428; next oid: 6346503
LOG: database system was not properly shut down; automatic recovery in
progressLOG: redo starts at 0/515D3718
LOG: ReadRecord: record with zero length at 0/515F5D88
LOG: redo done at 0/515F5D44
LOG: database system is ready
POSTGRES backend interactive interface
$Revision: 1.307 $ $Date: 2002/10/31 21:34:16 $
backend> select version();
blank
1: version (typeid = 25, len = -1, typmod = -1, byval = f)
----
1: version = "PostgreSQL 7.3 on i686-pc-linux-gnu, compiled by GCC
2.96" (typeid = 25, len = -1, typmod = -1, byval = f)
----
backend> select distinct platform_group_platform.platform_group_id,
gg.game_id, gg.genre_id, g.genre_category_id into temp tmp_browse_genre
from game_genre gg JOIN game_platform gp USING (game_id) JOIN
platform_group_platform USING (platform_id) JOIN game USING (game_id)
JOIN genre g USING (genre_id) where g.genre_id = gg.genre_id and
gp.approved = 1 and game.approved = 1
select distinct game.game_id::int4 as game_id,
pgp.platform_id::int4 as platform_id,
pgp.platform_group_id::int4 as platform_group_id,
upper(substr(game_title,1,1))::char(1) as game_title_first_letter into
temp tmp_browser1 from game JOIN game_platform gp USING(game_id) JOIN
platform_group_platform pgp USING(platform_id) where game.approved = 1
and gp.approved = 1
backend> backend>
Program received signal SIGSEGV, Segmentation fault.
0x08117354 in _mdfd_getrelnfd ()
(gdb) bt
#0 0x08117354 in _mdfd_getrelnfd ()
#1 0x0811739d in _mdfd_getseg ()
#2 0x08116dcc in mdwrite ()
#3 0x08117801 in smgrwrite ()
#4 0x0810f513 in LocalBufferAlloc ()
#5 0x0810dc70 in ReadBufferInternal ()
#6 0x0810dbeb in ReadBuffer ()
#7 0x08078852 in RelationGetBufferForTuple ()
#8 0x080762d6 in heap_insert ()
#9 0x080cd88c in ExecSelect ()
#10 0x080cd7fd in ExecutePlan ()
#11 0x080cccd6 in ExecutorRun ()
#12 0x0811a28f in ProcessQuery ()
#13 0x08118910 in pg_exec_query_string ()
#14 0x0811999d in PostgresMain ()
#15 0x080dec01 in main ()
#16 0x400f71c4 in __libc_start_main () from /lib/libc.so.6
(gdb)
--
Brian Hirt <bhirt@mobygames.com>
Brian Hirt <bhirt@mobygames.com> writes: > Anyway, each query executes by itself, but if i execute both queries in > the same session (order doesn't matter), the back end crashes. Maybe it > has to do with temp tables? I'm betting this is the same bug previously recognized in LocalBufferAlloc: http://fts.postgresql.org/db/mw/msg.html?mid=1361296 regards, tom lane
is it fixed in cvs? if so, i'll compile it to verify.
also, here is a slightly better stack:
Program received signal SIGSEGV, Segmentation fault.
_mdfd_getrelnfd (reln=0x0) at md.c:854
854 fd = RelationGetFile(reln);
(gdb) bt
#0 _mdfd_getrelnfd (reln=0x0) at md.c:854
#1 0x081172b5 in _mdfd_getseg (reln=0x0, blkno=270) at md.c:878
#2 0x08116ce4 in mdwrite (reln=0x0, blocknum=270, buffer=0x82f3850 "")
at md.c:461
#3 0x08117719 in smgrwrite (which=0, reln=0x0, blocknum=270,
buffer=0x82f3850 "") at smgr.c:328
#4 0x0810f42b in LocalBufferAlloc (reln=0x403624a0, blockNum=0,
foundPtr=0xbffff67b "") at localbuf.c:100
#5 0x0810db88 in ReadBufferInternal (reln=0x403624a0,
blockNum=4294967295,
bufferLockHeld=0) at bufmgr.c:144
#6 0x0810db03 in ReadBuffer (reln=0x403624a0, blockNum=4294967295)
at bufmgr.c:112
#7 0x08078852 in RelationGetBufferForTuple (relation=0x403624a0,
len=44,
otherBuffer=0) at hio.c:250
#8 0x080762d6 in heap_insert (relation=0x403624a0, tup=0x404a98f0,
cid=0)
at heapam.c:1162
#9 0x080cd7e0 in ExecSelect (slot=0x828c0c8, destfunc=0x81e6df8,
estate=0x828c000) at execMain.c:1165
#10 0x080cd751 in ExecutePlan (estate=0x828c000, plan=0x828ba68,
operation=CMD_SELECT, numberTuples=0,
direction=ForwardScanDirection,
destfunc=0x81e6df8) at execMain.c:1092
#11 0x080ccc2a in ExecutorRun (queryDesc=0x828bfd8, estate=0x828c000,
direction=ForwardScanDirection, count=0) at execMain.c:195
---Type <return> to continue, or q <return> to quit---
#12 0x0811a1a3 in ProcessQuery (parsetree=0x82772a0, plan=0x828ba68,
dest=Debug, completionTag=0xbffff900 "") at pquery.c:242
#13 0x08118824 in pg_exec_query_string (query_string=0x82760c0,
dest=Debug,
parse_context=0x823fc58) at postgres.c:838
#14 0x081198b1 in PostgresMain (argc=4, argv=0x8226bc8,
username=0x8228428 "postgres") at postgres.c:2016
#15 0x080deb41 in main (argc=4, argv=0xbffffa54) at main.c:235
#16 0x400f71c4 in __libc_start_main () from /lib/libc.so.6
(gdb)
On Mon, 2002-12-16 at 14:46, Tom Lane wrote:
> Brian Hirt <bhirt@mobygames.com> writes:
> > Anyway, each query executes by itself, but if i execute both queries in
> > the same session (order doesn't matter), the back end crashes. Maybe it
> > has to do with temp tables?
>
> I'm betting this is the same bug previously recognized in
> LocalBufferAlloc:
>
> http://fts.postgresql.org/db/mw/msg.html?mid=1361296
>
> regards, tom lane
--
Brian Hirt <bhirt@mobygames.com>