Re: FSM Corruption (was: Could not read block at end of the relation) - Mailing list pgsql-bugs

From Ronan Dunklau
Subject Re: FSM Corruption (was: Could not read block at end of the relation)
Date
Msg-id 1979116.usQuhbGJ8B@aivenlaptop
Whole thread Raw
In response to Re: FSM Corruption (was: Could not read block at end of the relation)  (Patrick Stählin <patrick.staehlin@aiven.io>)
List pgsql-bugs
Le mercredi 6 mars 2024, 11:59:43 CET Patrick Stählin a écrit :
> 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.

Good catch. Please find attached v2 of the patch.

--
Ronan Dunklau
Attachment

pgsql-bugs by date:

Previous
From: Patrick Stählin
Date:
Subject: Re: FSM Corruption (was: Could not read block at end of the relation)
Next
From: Tender Wang
Date:
Subject: Re: BUG #18314: PARALLEL UNSAFE function does not prevent parallel index build