From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, Michael Paquier <michael(at)paquier(dot)xyz>, 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-04-12 02:27:08 |
Message-ID: | 20240412022708.d6@rfd.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, Apr 11, 2024 at 12:01:09PM -0400, Peter Geoghegan wrote:
> On Wed, Mar 13, 2024 at 12:55 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > That's a reasonable thing to worry about. We could do wrong by trying too
> > hard to use an FSM slot, and we could do wrong by not trying hard enough.
>
> Although it's not related to the problem you're working on, it seems
> like a good opportunity to bring up a concern about the FSM that I
> don't believe was discussed at any point in the past few years: I
> wonder if the way that fsm_search_avail() sometimes updates
> fsmpage->fp_next_slot with only a shared lock on the page could cause
> problems. At the very least, it's weird that we allow it.
fsm_search_avail() treats an out-of-range fp_next_slot like zero, so I'm not
seeing a correctness issue. I bet changing it under an exclusive lock
wouldn't deliver better-optimized searches to an extent that pays for the
synchronization overhead, but it might.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2024-04-12 03:07:49 | Re: FSM Corruption (was: Could not read block at end of the relation) |
Previous Message | Sohan Wadalkar | 2024-04-11 17:15:49 | Facing issue while installing postgres14 on rhel 9.2 machine |