Re: Recovery inconsistencies, standby much larger than primary

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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Recovery inconsistencies, standby much larger than primary
Следующее
От: Tom Lane
Дата:
Сообщение: Re: mvcc catalo gsnapshots and TopTransactionContext