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
|
Список | 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 по дате отправления: