On 17.07.2013 02:18, Michael Paquier wrote:
On Tue, Jul 16, 2013 at 2:24 AM, Fujii Masao<masao.fu...@gmail.com>  wrote:
On Mon, Jul 8, 2013 at 6:16 PM, Heikki Linnakangas
<hlinnakan...@vmware.com>  wrote:
Ok, I've committed this patch now. Finally, phew!

I found that this patch causes the assertion failure. When I set up simple
replication environment and promoted the standby before executing any
transaction on the master, I got the following assertion failure.

2013-07-16 02:22:06 JST sby1 LOG:  received promote request
2013-07-16 02:22:06 JST sby1 FATAL:  terminating walreceiver process
due to administrator command
2013-07-16 02:22:06 JST sby1 LOG:  redo done at 0/20000F0
2013-07-16 02:22:06 JST sby1 LOG:  selected new timeline ID: 2
hrk:head-pgsql postgres$ 2013-07-16 02:22:06 JST sby1 LOG:  archive
recovery complete
TRAP: FailedAssertion("!(readOff == (XLogCtl->xlblocks[firstIdx] -
8192) % ((uint32) (16 * 1024 * 1024)))", File: "xlog.c", Line: 7048)
2013-07-16 02:22:12 JST sby1 LOG:  startup process (PID 37115) was
terminated by signal 6: Abort trap
2013-07-16 02:22:12 JST sby1 LOG:  terminating any other active server processes
Note that this is also reproducible even when trying to recover only
from archives without strrep.

Fixed, thanks for the report. While at it, I slightly refactored the way the buffer bookkeeping works. Instead of keeping track of the index of the last initialized buffer, keep track how far the buffer cache has been initialized in an XLogRecPtr variable (called XLogCtl->InitializedUpTo). That made the code slightly more readable IMO.

- Heikki


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to