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

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