Skip site navigation (1) Skip section navigation (2)

Archive recovery crashes on win32 in HEAD - hot standby related?

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Archive recovery crashes on win32 in HEAD - hot standby related?
Date: 2010-01-16 13:19:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I was going to test the walreceiver stuff, but it turns out that basic
archive recovery appears to be broken in HEAD. From what I can tell,
it's related to Hot Standby code.
I get this (this is all on win32 - I got the same on win64, but moved
back to win32 to make sure it's not an issue with the win64 code)

LOG:  restored log file "000000010000000000000001" from archive
LOG:  automatic recovery in progress
LOG:  initializing recovery connections
LOG:  redo starts at 0/1000020
LOG:  consistent recovery state reached at 0/1000050
LOG:  startup process (PID 1348) was terminated by exception 0xC0000005
HINT:  See C include file "ntstatus.h" for a description of the
hexadecimal value.
LOG:  terminating any other active server processes

postgres!hash_seq_init(struct HASH_SEQ_STATUS * status = 0x00002d66,
struct HTAB * hashp = 0x00000001)+0x13
postgres!KnownAssignedXidsRemoveMany(unsigned int xid = 0, char
keepPreparedXacts = 1 '')+0x73
postgres!ProcArrayApplyRecoveryInfo(struct RunningTransactionsData *
running = 0x00002d66)+0x1a
postgres!standby_redo(struct XLogRecPtr lsn = struct XLogRecPtr,
struct XLogRecord * record = 0x00000000)+0x80
postgres!AuxiliaryProcessMain(int argc = <Memory access error>, char
** argv = <Memory access error>)+0x435
postgres!SubPostmasterMain(int argc = 3614962, char ** argv = 0x003728fd)+0x2b2
postgres!main(int argc = <Memory access error>, char ** argv = <Memory
access error>)+0x168
WARNING: Stack unwind information not available. Following frames may be wrong.

very trivial install - one master with zero activity, archiving with
plain "copy" commands...

Not knowing that code very well at this time, but is this perhaps a
structure not being properly initialized in EXEC_BACKEND case?

 Magnus Hagander


pgsql-hackers by date

Next:From: Euler Taveira de OliveiraDate: 2010-01-16 13:21:24
Subject: Re: Streaming replication and non-blocking I/O
Previous:From: Dimitri FontaineDate: 2010-01-16 13:08:21
Subject: Re: Hot Standby and handling max_standby_delay

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group