On 2014-02-06 18:42:05 -0500, Tom Lane wrote:
> Greg Stark <stark@mit.edu> writes:
> > On Thu, Feb 6, 2014 at 11:48 PM, Andres Freund <andres@2ndquadrant.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.GJ20248@awork2.anarazel.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
