Re: Recovery inconsistencies, standby much larger than primary

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Recovery inconsistencies, standby much larger than primary
Дата
Msg-id CAM-w4HPh6_0dO9Uri-6PFJQVrCpcesKoq4mj0i2108VXyXm-TQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Recovery inconsistencies, standby much larger than primary  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Recovery inconsistencies, standby much larger than primary  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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.

> Are there any other relations that are as big as the corrupted relations
> got extended to?

I was wondering the same thing. But no, the extended file is 39GB
larger than the next largest relation.

Also, the final block in the first relation is clearly a version of
the same block from the correct location. Look at the ctids and the
xids on the rows for lp 3 in the attached file for example. That
second copy is from the location in the xlog record.


--
greg

Вложения

В списке pgsql-hackers по дате отправления:

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