| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Recovery inconsistencies, standby much larger than primary |
| Date: | 2014-01-31 11:46:09 |
| Message-ID: | CAM-w4HO9+-zCY_LiOKkoanHcH3rDT9VLPSYLMBobVCXaYODj2A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-01-31 11:52:39 | Re: Recovery inconsistencies, standby much larger than primary |
| Previous Message | Yugo Nagata | 2014-01-31 11:31:04 | Re: Fwd: Proposal: variant of regclass |