Re: Recovery inconsistencies, standby much larger than primary

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Recovery inconsistencies, standby much larger than primary
Дата
Msg-id 20140131155643.GK13199@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Recovery inconsistencies, standby much larger than primary  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Recovery inconsistencies, standby much larger than primary  (Greg Stark <stark@mit.edu>)
Список pgsql-hackers
On 2014-01-31 10:33:16 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > It's interesting that the smgr gets this wrong then (as also evidenced
> > by the fact that relation_size does as well). Could you please do a ls
> > -l path/to/relfilenode*?
> 
> IIRC, smgrnblocks will stop as soon as it finds a segment that is not
> 1GB in size.  Could you check the lengths of all segments for that
> relation?

I am not sure that explains the issue, but I think the redo action for
truncation is not safe across crashes.  A XLOG_SMGR_TRUNCATE will just
do a smgrtruncate() (and then mdtruncate) which will iterate over the
segments starting at 0 till mdnblocks()/segment_size and *truncate* but
not delete individual segment files that are not needed anymore, right?
If we crash in the midst of that a new mdtruncate() will be issued, but
it will get a shorter value back from mdnblocks().

Am I missing something?

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
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Recovery inconsistencies, standby much larger than primary