8.5alpha3 hot standby crash report (DatabasePath related?) - Mailing list pgsql-hackers

From Robert Treat
Subject 8.5alpha3 hot standby crash report (DatabasePath related?)
Date
Msg-id 201001071441.13392.xzilla@users.sourceforge.net
Whole thread Raw
Responses Re: 8.5alpha3 hot standby crash report (DatabasePath related?)  (Simon Riggs <simon@2ndQuadrant.com>)
Re: 8.5alpha3 hot standby crash report (DatabasePath related?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: 8.5alpha3 hot standby crash report (DatabasePath related?)  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Howdy folks, 

Doing some testing with 8.5alpha3, my standby crashed this morning whilst 
doing some testing. Seems I have a core file, so thought I would send a report.

Version: PostgreSQL 8.5alpha3 on i386-pc-solaris2.10, compiled by GCC gcc 
(GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath), 32-bit

Error in the log was simply this:
LOG:  restored log file "000000010000000300000032" from archive
LOG:  startup process (PID 385) was terminated by signal 11
LOG:  terminating any other active server processes

info from core file was:

postgres@postgresdev[/export/home/postgres/pgwork/data/slave]dbx 
/export/home/postgres/pgwork/inst/slave/bin/postgres core 
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.6' in your 
.dbxrc
Reading postgres
core file header read successfully
Reading ld.so.1
Reading libnsl.so.1
Reading librt.so.1
Reading libsocket.so.1
Reading libm.so.2
Reading libc.so.1
Reading libaio.so.1
Reading libmd.so.1
program terminated by signal SEGV (no mapping at the fault address)
0xfedb578c: strlen+0x000c:      movl     (%eax),%edx
Current function is RelationCacheInitFileInvalidate4237           snprintf(initfilename, sizeof(initfilename),
"%s/%s",
(dbx) where [1] strlen(0x0), at 0xfedb578c  [2] _ndoprnt(0x8417d81, 0x8042e7c, 0x8042e50, 0x0), at 0xfee0d976  [3]
snprintf(0x8042e90,0x400, 0x8417d7f, 0x0, 0x8417d30, 0x2f676f6c, 
 
0x4f434552, 0x59524556), at 0xfee10734 
=>[4] RelationCacheInitFileInvalidate(beforeSend = '\0'), line 4237 in 
"relcache.c" [5] xact_redo_commit(xlrec = 0x84ed434, xid = 0, lsn = RECORD), line 4414 in 
"xact.c" [6] StartupXLOG(), line 5834 in "xlog.c" [7] StartupProcessMain(), line 8359 in "xlog.c" [8]
AuxiliaryProcessMain(argc= 2, argv = 0x80475e0), line 408 in 
 
"bootstrap.c" [9] StartChildProcess(type = 134510104), line 4218 in "postmaster.c" [10] PostmasterMain(argc = 3, argv =
0x84c6e00),line 1061 in "postmaster.c" [11] main(argc = 3, argv = 0x84c6e00), line 188 in "main.c"
 
(dbx) print initfilename
initfilename = "XLOG"
(dbx) list4237           snprintf(initfilename, sizeof(initfilename), "%s/%s",4238
DatabasePath,RELCACHE_INIT_FILENAME);4239   4240           if (beforeSend)4241           {4242                   /* no
interlockneeded here */4243                   unlink(initfilename);4244           }4245           else4246           {
 
(dbx) print DatabasePath
DatabasePath = (nil)

Theo mentioned that he expects the above would work under Linux, but that we 
need DatabasePath to not be null in the above. 

FWIW, the SQL I was running on the master did involve two create database 
commands back to back.  

LMK if you have any questions. 

-- 
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Hot Standy introduced problem with query cancel behavior
Next
From: Robert Haas
Date:
Subject: Re: Streaming replication and postmaster signaling