Re: Recovery inconsistencies, standby much larger than primary

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Recovery inconsistencies, standby much larger than primary
Date: 2014-01-31 11:52:39
Message-ID: 20140131115239.GE13199@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2014-01-31 12:29:41 Re: pg_basebackup and pg_stat_tmp directory
Previous Message Greg Stark 2014-01-31 11:46:09 Re: Recovery inconsistencies, standby much larger than primary