Thread: BUG #5703: Streaming replication: FATAL: bad buffer id: 0

BUG #5703: Streaming replication: FATAL: bad buffer id: 0

From
"Evgeniy"
Date:
The following bug has been logged online:

Bug reference:      5703
Logged by:          Evgeniy
Email address:      efreet@efreet.ru
PostgreSQL version: 9.0.1
Operating system:   linux
Description:        Streaming replication: FATAL:  bad buffer id: 0
Details:

SR doesn't work for me:

Standby server dies after some minutes with FATAL message:

2010-10-11 19:12:17.129 MSD [13864/0]: [5-1] user=,db= LOG:  consistent
recovery state reached at E/A5DCD3A8
2010-10-11 19:12:17.139 MSD [13864/0]: [6-1] user=,db= FATAL:  bad buffer
id: 0
2010-10-11 19:12:17.139 MSD [13864/0]: [7-1] user=,db= CONTEXT:  xlog redo
Delete list pages (16), node: 1663/18241/93940 blkno: 21207
2010-10-11 19:12:17.191 MSD [13855/0]: [1-1] user=,db= LOG:  startup process
(PID 13864) exited with exit code 1
2010-10-11 19:12:17.192 MSD [13855/0]: [2-1] user=,db= LOG:  terminating any
other active server processes


What else logs or configuration files should I attach?

Re: BUG #5703: Streaming replication: FATAL: bad buffer id: 0

From
Tom Lane
Date:
"Evgeniy" <efreet@efreet.ru> writes:
> Standby server dies after some minutes with FATAL message:

> 2010-10-11 19:12:17.129 MSD [13864/0]: [5-1] user=,db= LOG:  consistent
> recovery state reached at E/A5DCD3A8
> 2010-10-11 19:12:17.139 MSD [13864/0]: [6-1] user=,db= FATAL:  bad buffer
> id: 0
> 2010-10-11 19:12:17.139 MSD [13864/0]: [7-1] user=,db= CONTEXT:  xlog redo
> Delete list pages (16), node: 1663/18241/93940 blkno: 21207

Hmm ... that seems to be a GIN index message ... and a bit of looking at
the GIN code says that its xlog replay logic is many bricks shy of a
load.  I think SR is exposing a pre-existing problem here.

            regards, tom lane

Re: BUG #5703: Streaming replication: FATAL: bad buffer id: 0

From
Tom Lane
Date:
I wrote:
> Hmm ... that seems to be a GIN index message ... and a bit of looking at
> the GIN code says that its xlog replay logic is many bricks shy of a
> load.  I think SR is exposing a pre-existing problem here.

Actually, it's been broken since 8.2 :-(.  I've applied a patch.

            regards, tom lane