Обсуждение: RE: [ADMIN] FATAL 1: btree: cannot split if start (2) >= maxoff (2)

Поиск
Список
Период
Сортировка

RE: [ADMIN] FATAL 1: btree: cannot split if start (2) >= maxoff (2)

От
"Jackson, DeJuan"
Дата:
>   Hi,
>
>   Please, what can I do to solve this "FATAL 1:  btree: cannot split
> if start (2) >= maxoff (2)" error messages ? I use v. 6.3.2 + btree
> patch
> and almost every time I send a "create function" I receive this
> message on pg_proc.
>   pg_proc has 972 tuples and my functions use from 1k to 4k in prosrc
> .
>   I've searched in the archives but all that I found said something
> like "drop & recreate the database" or "restart postgres", but I can't
>
> do this every time.
But, have you done this at all.  It sounds like the index on pg_proc has
gotten corrupted.  If this is the case you have one of two options:
    1. recreate the database, thereby updating the index.
  or
    2. figure out how to recreate the index and just drop it.  A
good place to look to figure that out would be initdb, but I would
recommend trying it out on a production database.  In fact I'd use a
whole different machine.
Well, don't know if this will help or hurt, but here it is.
        -DEJ

>   Please, any help ?
>
>

RE: [ADMIN] FATAL 1: btree: cannot split if start (2) >= maxoff (2)

От
Mateus Cordeiro Inssa
Дата:
Jackson, DeJuan writes:
 > >   Please, what can I do to solve this "FATAL 1:  btree: cannot split
 > > if start (2) >= maxoff (2)" error messages ? I use v. 6.3.2 + btree
 > > patch
 > > and almost every time I send a "create function" I receive this
 > > message on pg_proc.
 > >   pg_proc has 972 tuples and my functions use from 1k to 4k in prosrc

 > But, have you done this at all.  It sounds like the index on pg_proc has
 > gotten corrupted.  If this is the case you have one of two options:
 >     1. recreate the database, thereby updating the index.
 >   or
 >     2. figure out how to recreate the index and just drop it.  A
 > good place to look to figure that out would be initdb, but I would
 > recommend trying it out on a production database.  In fact I'd use a
 > whole different machine.
 > Well, don't know if this will help or hurt, but here it is.

  I've already recreated the database. I drop all my functions e
recreated again and at least I can do a "vacuum pg_proc" without
errors.
  Now, if I create a little function, ok, but if I create a function >
3 k I get this error again. It seems that there isn't any problem with
the index (vacuum pg_proc still works), but in the code  that makes
the index "grow". I don't know why there is an index to filed prosrc
of pg_proc !

Mateus Cordeiro Inssa
---------------------
Innova Producoes Digitais
---------------------
Linux User: 76186
ICQ (KXicq): 15243895
---------------------
mateus@innova.com.br
mateus@einstein.innova.com.br

Thu Sep  3 16:11:52 EST 1998