Re: FSM Corruption (was: Could not read block at end of the relation)
От | Patrick Stählin |
---|---|
Тема | Re: FSM Corruption (was: Could not read block at end of the relation) |
Дата | |
Msg-id | aede09f6-be0c-e10b-6a4f-c8e021a014c9@aiven.io обсуждение исходный текст |
Ответ на | Re: FSM Corruption (was: Could not read block at end of the relation) (Ronan Dunklau <ronan.dunklau@aiven.io>) |
Ответы |
Re: FSM Corruption (was: Could not read block at end of the relation)
|
Список | pgsql-bugs |
On 3/6/24 10:31, Ronan Dunklau wrote: > Le mardi 5 mars 2024, 00:05:03 CET Noah Misch a écrit : >> I would guess this one is more risky from a performance perspective, since >> we'd be adding to a hotter path under RelationGetBufferForTuple(). Still, >> it's likely fine. > > I ended up implementing this in the attached patch. The idea is that we detect > if the FSM returns a page past the end of the relation, and ignore it. > In that case we will fallback through the extension mechanism. @@ -582,7 +583,17 @@ RelationGetBufferForTuple(Relation relation, Size len, * We have no cached target page, so ask the FSM for an initial * target. */ + nblocks = RelationGetNumberOfBlocks(relation); targetBlock = GetPageWithFreeSpace(relation, targetFreeSpace); I'd move the fetching of nblocks to after getting the targetBlock. This avoids extending the relation in the unlikely event of a FSM/relation extension in-between those two calls. Patrick
В списке pgsql-bugs по дате отправления: