Heikki Linnakangas <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers