Re: [HACKERS] Error "vacuum pg_proc"
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Error "vacuum pg_proc" |
Дата | |
Msg-id | 23238.946243249@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Error "vacuum pg_proc" (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Error "vacuum pg_proc"
(Bruce Momjian <pgman@candle.pha.pa.us>)
|
Список | pgsql-hackers |
I wrote: > Mateus Cordeiro Inssa <mateus@ifnet.com.br> writes: >> I got this error vacuuming pg_proc: >> ERROR: _bt_endpoint: leftmost page (20) has not leftmost flag > Hmm, I wonder if this could be yet another manifestation of the problems > that btree indexes have with oversized key values. Do you have any > procedures with long definitions? "Long" in this context means over > about 4K. I spent some more time looking into this, and found out that actually the safe upper limit for btree index entries is not ~ BLCKSZ/2, but ~ BLCKSZ/3. btree needs to be able to insert two items on every page, but it *also* keeps an extra item (the "high key") on non-rightmost pages. So if any item exceeds one-third the available space, you run a risk of failure depending on what page it ends up on and what else is on that same page. It turns out that for an index on a single text column, the maximum safe text length is 2700 bytes. So the correct check for dangerous procedure definitions in 6.5.* is select proname from pg_proc where length(prosrc) > 2700; I have committed a check for dangerously long index entries into both current sources and REL6_5 branch. The patch is attached if you want to add it to your installation right away. Note that this only defends against oversize new entries; if you've already got oversize index entries, you still have trouble waiting to happen... regards, tom lane *** src/backend/access/nbtree/nbtinsert.c.orig Wed Sep 1 13:54:00 1999 --- src/backend/access/nbtree/nbtinsert.c Sun Dec 26 15:44:15 1999 *************** *** 268,273 **** --- 268,285 ---- * consistent */ /* + * Check whether the item can fit on a btree page at all. + * (Eventually, we ought to try to apply TOAST methods if not.) + * We actually need to be able to fit three items on every page, + * so restrict any one item to 1/3 the per-page available space. + * Note that at this point, itemsz doesn't include the ItemId. + */ + if (itemsz > (PageGetPageSize(page)-sizeof(PageHeaderData)-MAXALIGN(sizeof(BTPageOpaqueData)))/3 - sizeof(ItemIdData)) + elog(ERROR, "btree: index item size %d exceeds maximum %d", + itemsz, + (PageGetPageSize(page)-sizeof(PageHeaderData)-MAXALIGN(sizeof(BTPageOpaqueData)))/3 - sizeof(ItemIdData)); + + /* * If we have to insert item on the leftmost page which is the first * page in the chain of duplicatesthen: 1. if scankey == hikey (i.e. * - new duplicate item) then insert it here; 2. if scankey < hikey
В списке pgsql-hackers по дате отправления: