Re: Recovery inconsistencies, standby much larger than primary
От | Andres Freund |
---|---|
Тема | Re: Recovery inconsistencies, standby much larger than primary |
Дата | |
Msg-id | 20140131115239.GE13199@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Recovery inconsistencies, standby much larger than primary (Greg Stark <stark@mit.edu>) |
Ответы |
Re: Recovery inconsistencies, standby much larger than primary
|
Список | 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 по дате отправления: