Re: FSM Corruption (was: Could not read block at end of the relation)

From: Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: 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-03-21 13:51:25
Message-ID: 2493745.irdbgypaU6@aivenlaptop
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Le samedi 16 mars 2024, 05:58:34 CET Noah Misch a écrit :
> > Does "that benchmark" refer to "unlogged tables, 4 parallel copies",
> > "logged tables, 4 parallel copies", or something else?

Sorry I was quite busy, and will not find time to run more benchmarks until
next week but I'll get back to it.

It was 4 parallel copies, logged tables. Results for unlogged tables are
similar.

> >
> > > master: 15.05s
> > > patched: 15.24s (+1.25%)
> > >
> > > If I remove the best and worst run for each of those, the difference
> > > falls at +0.7%.
> >
> > To get some additional perspective on the benchmark, how hard would it be
> > to run one or both of the following? Feel free to decline if difficult.
> >
> > - Make GetPageWithFreeSpace() just "return InvalidBlockNumber", then rerun
> > the>
> > benchmark. This should be a lot slower. If not, the bottleneck is
> > somewhere unexpected, and we'd need a different benchmark.

Hum, it doesn't change much so that benchmark does not indeed exercise that
code too aggressively. I was thinking my initial benchmark for the very first
naive version of the patch could work, but I'm afraid it won't show much as
the table size will be cached soon enough.

> >
> > - Get profiles with both master and patched. (lseek or freespace.c
> > functions>
> > rising by 0.1%-1% would fit what we know.)
>

I'll try to run that asap, probably next week unfortunately.

> Forgot one more:
>
> - Your earlier version of the patch, with fewer lseek() but more disuse of
> FSM entries.

Noted.

--
Ronan Dunklau

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Robert Haas 2024-03-21 16:15:03 Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
Previous Message Andrey M. Borodin 2024-03-21 05:46:43 Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum