Re: Recovery inconsistencies, standby much larger than primary - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Recovery inconsistencies, standby much larger than primary
Date
Msg-id 20140206224842.GM12016@awork2.anarazel.de
Whole thread Raw
In response to Re: Recovery inconsistencies, standby much larger than primary  (Greg Stark <stark@mit.edu>)
Responses Re: Recovery inconsistencies, standby much larger than primary  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On 2014-02-06 23:41:19 +0100, Greg Stark wrote:
> The problem with the bgwriter being at fault is that from what I can
> see the bgwriter will never extend a file. That means the xlog
> recovery code must have done it. That means even if the bgwriter came
> along and looked at the buffer we just read in it would already be too
> late to cause mischief. The xlog code extends the file *first* then
> reads in the backup block into a buffer. I can't see how it could
> corrupt the stack or the wal recovery buffer in the window between
> reading in the wal buffer and deciding to extend the relation.

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.
Are there any other relations that are as big as the corrupted relations
got extended to?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Recovery inconsistencies, standby much larger than primary
Next
From: Tom Lane
Date:
Subject: Re: mvcc catalo gsnapshots and TopTransactionContext