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