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
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 |