From: | Patrick Stählin <patrick(dot)staehlin(at)aiven(dot)io> |
---|---|
To: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, Noah Misch <noah(at)leadboat(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: FSM Corruption (was: Could not read block at end of the relation) |
Date: | 2024-03-06 10:59:43 |
Message-ID: | aede09f6-be0c-e10b-6a4f-c8e021a014c9@aiven.io |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Ronan Dunklau | 2024-03-06 11:08:38 | Re: FSM Corruption (was: Could not read block at end of the relation) |
Previous Message | Devrim Gündüz | 2024-03-06 10:35:39 | Re: Issue with PostgreSQL 11 RPM Package Availability |