Re: Recovery inconsistencies, standby much larger than primary - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Recovery inconsistencies, standby much larger than primary
Date
Msg-id 20140131115239.GE13199@alap3.anarazel.de
Whole thread Raw
In response to Re: Recovery inconsistencies, standby much larger than primary  (Greg Stark <stark@mit.edu>)
Responses Re: Recovery inconsistencies, standby much larger than primary  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On 2014-01-31 11:46:09 +0000, Greg Stark wrote:
> On Fri, Jan 31, 2014 at 11:26 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > The slightly more likely explanation for transient errors is that you
> > hit the vacuum bug (061b079f89800929a863a692b952207cadf15886). That had
> > only taken effect if HS has already assembled a snapshot, which can make
> > such an error vanish after a restart...
> 
> Which one, there seem to be several....
> 
> So this seems like it's more likely to be a symptom of whatever is
> causing the table to grow than a cause? That is, there's some bug
> causing the standby to extend the btree dramatically resulting in lots
> of uninitialized pages and touching those pages triggers this bug. But
> this doesn't explain why the btree is being extended I don't think.

I don't think anything we've talked about so far is likely to explain
the issue. I don't have time atm to look closer, but what I'd do is try
to look if there are any pages with valid LSNs on the standby in the
bloated area... That then might give you a hint where to look.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Recovery inconsistencies, standby much larger than primary
Next
From: Fujii Masao
Date:
Subject: Re: pg_basebackup and pg_stat_tmp directory