From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Recovery inconsistencies, standby much larger than primary |
Date: | 2014-02-06 23:52:19 |
Message-ID: | 20140206235219.GO12016@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-02-06 18:42:05 -0500, Tom Lane wrote:
> Greg Stark <stark(at)mit(dot)edu> writes:
> > On Thu, Feb 6, 2014 at 11:48 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> >> That's not necessarily true. If e.g. the buffer mapping would change
> >> racily, the result write from the bgwriter could very well end up
> >> increasing the file size, leaving a hole inbetween its write and the
> >> original size.
>
> > a) the segment isn't sparse and b) there were whole segments full of
> > nuls between the end of the tables and the final blocks.
>
> > So the file was definitely extended by Postgres, not the OS and the
> > bgwriter passes EXTENSION_FAIL which means it wouldn't create those
> > intervening segments.
>
> But ... when InRecovery, md.c will create such segments too. We had
> dismissed that on the grounds that the files would be sparse because
> of the way md.c creates them. However, it is real damn hard to see
> how the loop in XLogReadBufferExtended could've accessed a bogus block,
> other than hardware misfeasance which I don't believe any more than
> you do. The blkno that's passed to that function came directly out
> of a WAL record that's in the private memory of the startup process
> and recently passed a CRC check. You'd have to believe some sort
> of asynchronous memory clobber inside the startup process.
That reminds me, not that I directly see how it could be responsible,
there's still 20131029011623(dot)GJ20248(at)awork2(dot)anarazel(dot)de ff. around. I
don't think we came to a agreement in that thread how to fix the
problem.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2014-02-07 01:02:27 | Re: adt Makefile, was Re: jsonb and nested hstore |
Previous Message | Andrew Dunstan | 2014-02-06 23:47:31 | Re: jsonb and nested hstore |