Thread: Invalid pages in WAL
I've had a private report of these error messages in a test of Hot Standby, but IMHO these aren't related to that patch. It seems more likely to be related to the new VACUUM code? Certainly hot standby does nothing to the normal flow of existing WAL records. LOG: database system was interrupted; last known up at 2008-12-16 12:56:57 EST LOG: database system was not properly shut down; automatic recovery in progress LOG: redo starts at 0/655A68 LOG: record with zero length at 0/658150 LOG: redo done at 0/658080 WARNING: page 35 of relation base/11517/1249 did not exist WARNING: page 32 of relation base/11517/1249 did not exist WARNING: page 33 of relation base/11517/1249 did not exist WARNING: page 34 of relation base/11517/1249 did not exist PANIC: WAL contains references to invalid pages The WAL record was destroyed before it could be analysed, so we can't do much for now. Ideas please? -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
Simon Riggs wrote: > I've had a private report of these error messages in a test of Hot > Standby, but IMHO these aren't related to that patch. It seems more > likely to be related to the new VACUUM code? Certainly hot standby does > nothing to the normal flow of existing WAL records. > > LOG: database system was interrupted; last known up at 2008-12-16 > 12:56:57 EST > LOG: database system was not properly shut down; automatic recovery in > progress > LOG: redo starts at 0/655A68 > LOG: record with zero length at 0/658150 > LOG: redo done at 0/658080 > WARNING: page 35 of relation base/11517/1249 did not exist > WARNING: page 32 of relation base/11517/1249 did not exist > WARNING: page 33 of relation base/11517/1249 did not exist > WARNING: page 34 of relation base/11517/1249 did not exist > PANIC: WAL contains references to invalid pages > > The WAL record was destroyed before it could be analysed, so we can't do > much for now. Hmm, could well be related to the visibility map or FSM. Although those messages suggest that it's a heap/index page that's missing, not FSM or VM page. Any idea how to reproduce that? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On Wed, 2008-12-17 at 17:12 +0200, Heikki Linnakangas wrote: > Hmm, could well be related to the visibility map or FSM. Although those > messages suggest that it's a heap/index page that's missing, not FSM or > VM page. Any idea how to reproduce that? Regrettably, none. I will ask to see if the sequence of actions can be repeated, but that may not get us anywhere. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
Simon Riggs <simon@2ndQuadrant.com> writes: > On Wed, 2008-12-17 at 17:12 +0200, Heikki Linnakangas wrote: > >> Hmm, could well be related to the visibility map or FSM. Although those >> messages suggest that it's a heap/index page that's missing, not FSM or >> VM page. Any idea how to reproduce that? > > Regrettably, none. I will ask to see if the sequence of actions can be > repeated, but that may not get us anywhere. This was with CVS HEAD? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!
On Wed, 2008-12-17 at 15:43 +0000, Gregory Stark wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > > On Wed, 2008-12-17 at 17:12 +0200, Heikki Linnakangas wrote: > > > >> Hmm, could well be related to the visibility map or FSM. Although those > >> messages suggest that it's a heap/index page that's missing, not FSM or > >> VM page. Any idea how to reproduce that? > > > > Regrettably, none. I will ask to see if the sequence of actions can be > > repeated, but that may not get us anywhere. > > This was with CVS HEAD? Yes -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support