failed assertion and panic in standby mode

Hi,

i was trying recent HS and get this when trying to start the standby,
actually i was expecting a crash because i use full_page_writes=off
and i guess it won't work.
Maybe we could say full_page_writes=off and wal_level=hot_standby are
conflicting and avoid such setup?
"""
LOG: database system was interrupted; last known up at 2010-04-29 23:38:53 ECT
LOG: entering standby mode
LOG: restored log file "000000010000000000000004" from archive
LOG: redo starts at 0/452A898
TRAP: FailedAssertion("!(( (metabuffer) != 0 && (metabuffer) >=
-NLocBuffer && (metabuffer) <= NBuffers ))", File: "ginxlog.c", Line:
590)
LOG: startup process (PID 8287) was terminated by signal 6: Aborted
LOG: terminating any other active server processes
"""

then i try again, i make the backup when running "make installcheck"
for the second time and i get this:
"""
LOG: database system was interrupted; last known up at 2010-04-29 23:48:13 ECT
LOG: entering standby mode
LOG: restored log file "00000001000000000000000B" from archive
LOG: redo starts at 0/B000020
WARNING: could not open directory "base/40596": No existe el fichero
o el directorio
CONTEXT: xlog redo drop db: dir 40596/1663
WARNING: some useless files may be left behind in old database
directory "base/40596"
CONTEXT: xlog redo drop db: dir 40596/1663
LOG: restored log file "00000001000000000000000C" from archive
PANIC: btree_redo: unknown op code 208
CONTEXT: xlog redo UNKNOWN
LOG: startup process (PID 9264) was terminated by signal 6: Aborted
LOG: terminating any other active server processes
"""

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> writes:
> i was trying recent HS and get this when trying to start the standby,

> TRAP: FailedAssertion("!(( (metabuffer) != 0 && (metabuffer) >=
> -NLocBuffer && (metabuffer) <= NBuffers ))", File: "ginxlog.c", Line:
> 590)

Hm, can you provide a test case?

regards, tom lane

On Fri, Apr 30, 2010 at 12:03 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> writes:
>> i was trying recent HS and get this when trying to start the standby,
>
>> TRAP: FailedAssertion("!(( (metabuffer) != 0 && (metabuffer) >=
>> -NLocBuffer && (metabuffer) <= NBuffers ))", File: "ginxlog.c", Line:
>> 590)
>
> Hm, can you provide a test case?
>

i wasn't able to reproduce the assertion, although i'm pretty sure
what i did when i got that...
it's late for me now, tomorrow i will try again and will post the exact steps

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

Jaime Casanova wrote:
> i was trying recent HS and get this when trying to start the standby,
> actually i was expecting a crash because i use full_page_writes=off
> and i guess it won't work.
> Maybe we could say full_page_writes=off and wal_level=hot_standby are
> conflicting and avoid such setup?

It's supposed to work.

> PANIC: btree_redo: unknown op code 208
> CONTEXT: xlog redo UNKNOWN

Hmm, I see a bug in btree_redo handling of XLOG_BTREE_REUSE_PAGE. If hot
standby is not enabled in the standby, it chokes on that record type.
It's missing from btree_desc too.

Fixed.

This demonstrates that there really has been little testing of warm
standby with hot standby disabled :-).

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Fri, 2010-04-30 at 09:35 +0300, Heikki Linnakangas wrote:

> Hmm, I see a bug in btree_redo handling of XLOG_BTREE_REUSE_PAGE. If
> hot standby is not enabled in the standby, it chokes on that record
> type. It's missing from btree_desc too.

Yep, correct fix.

> This demonstrates that there really has been little testing of warm
> standby with hot standby disabled :-).

Agreed, exactly why I'm not convinced turning it off makes you safer.
Most people will turn it on and so it will remain a less well tested
path through the code.

--
Simon Riggs www.2ndQuadrant.com