Re: FSM Corruption (was: Could not read block at end of the relation)
От | Noah Misch |
---|---|
Тема | Re: FSM Corruption (was: Could not read block at end of the relation) |
Дата | |
Msg-id | 20240412022708.d6@rfd.leadboat.com обсуждение исходный текст |
Ответ на | Re: FSM Corruption (was: Could not read block at end of the relation) (Peter Geoghegan <pg@bowt.ie>) |
Список | 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@leadboat.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.
В списке pgsql-bugs по дате отправления: