Re: New FSM patch

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> No, FANOUT^4 doesn't fit in int, good catch. Actually, FANOUTPOWERS
> table doesn't need to go that far, so that's just a leftover. It only
> needs to have DEPTH elements. However, we have the same problem if
> DEPTH==3, FANOUT^4 will not fit into int. I put a comment there.
> Ideally, the 4th element would be #iffed out, but I couldn't immediately
> figure out how to do that.

This is a "must fix" IMHO --- I don't plan to tolerate a scary compiler
warning ...

BTW, the comment about and computation of DEPTH are wrong anyway.
We support up to 2^32-1 pages, so I think the cutoff should be 1626.

I did a bit of testing and immediately got an Assert failure:

regression=# create table foo as select x from generate_series(1,100000) x;
SELECT
regression=# create index fooi on foo(x);
CREATE INDEX
regression=# delete from foo;
DELETE 100000
regression=# vacuum foo;
VACUUM
regression=# vacuum foo;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

The reason is that the Assert in FSM_CATEGORY_AVAIL is failing:
TRAP: FailedAssertion("!(x < 8192)", File: "freespace.c", Line: 46)
LOG: server process (PID 17691) was terminated by signal 6: Aborted

because RecordFreeIndexPage passes in BLCKSZ which is an illegal
value. Maybe use BLCKSZ-1 instead?

The scary part of that is that it gets through the regression tests ---
doesn't leave one with a warm feeling about how much of VACUUM gets
exercised by regression.

I take it the comment at the top of indexfsm.c about using one bit per
page should be recast as a possible future improvement?

regards, tom lane