postmaster error: FATAL 1: btree: cannot split if start (2) >= maxoff (2)

Поиск
Список
Период
Сортировка
От Toby C Patterson
Тема postmaster error: FATAL 1: btree: cannot split if start (2) >= maxoff (2)
Дата
Msg-id 199911052253.OAA27928@regulus.cs.pdx.edu
обсуждение исходный текст
Список pgsql-general
Hiya.  I would like advice about how to proceed with the following
error: "FATAL 1:  btree: cannot split if start (2) >= maxoff (2)".  I've
browsed online documentation and many of the mailing list archives but
cannot find any mention of this error.

In summary, I am using plpgsql to create a trig that imposes
integrity checks on the NEW record.  When I try to load the plpgsql
block, the command interpreter (psql) sometimes dies and the above error is
displayed in my postmaster log file.  Interesting, sometimes the
command interpreter does not die.  Here's more specific info.

Here's the info.
OS:            SunOS hide.machine.pdx.edu 5.7
            Generic_106541-05 sun4u sparc SUNW,Ultra-30
Postgres Ver:        6.5.2, compiled w/ defaults
postmaster commandline:    `postmaster -d >>& pm.log &`
psql commandline:    `psql -s -f fleas_accounts_trig.sql`
plpgsql code:        # Its quite lengthy.

 CREATE FUNCTION fleas_accounts_parse () RETURNS OPAQUE AS '
 DECLARE
    a_record     RECORD;
    v_username   fleas_human_info.username%TYPE;
    v__id        fleas_human_info._id%TYPE;
    v_local_user fleas_human_info.username%TYPE;
 BEGIN

    -- check NEW._id
    IF NEW._id ISNULL THEN
       -- if no NEW._id, then we default to the active account defined
       -- by NEW._username
       IF NEW._username ISNULL THEN
          RAISE EXCEPTION ''Field _id or _username required'';
       END IF;
       SELECT _id INTO v__id FROM fleas_human_info
          WHERE username = NEW._username
            AND _active = TRUE;
       IF NOT FOUND THEN
          RAISE EXCEPTION ''No active human_info record found for %'',
                 NEW._username;
       END IF;
       NEW._id = v__id;
    ELSE
       IF count(*) = 0 FROM fleas_human_info
       WHERE _id = NEW._id AND _active = TRUE THEN
          RAISE EXCEPTION ''No active human_info record found for %'', NEW._id;
       END IF;
    END IF;

    -- Check if _account_type is a valid _account_type.
    IF NEW._account_type NOTNULL THEN
       IF count(*) = 0 FROM valid_cluster
          where cluster_name = NEW._account_type THEN
             RAISE EXCEPTION ''Invalid _account_type value %'',
                 NEW._account_type;
       END IF;
    ELSE
       RAISE EXCEPTION ''No account type defined'';
    END IF;

    -- check if an account listing for this type of account already exists
    -- for this user identified by NEW._id
    IF count(*) != 0 FROM fleas_accounts
    WHERE _id = NEW._id AND _account_type = NEW._account_type THEN
       RAISE EXCEPTION ''An account for % already exists'', NEW._account_type;
    END IF;

    -- Check if dept is a valid dept.
    IF NEW.dept NOTNULL THEN
       IF count(*) = 0 FROM valid_dept
          where dept_code = NEW.dept THEN
             RAISE EXCEPTION ''Invalid dept value %'', NEW.dept;
       END IF;
    END IF;

    -- Check if status is a valid status.
    IF NEW.status NOTNULL THEN
       IF count(*) = 0 FROM valid_status
          where status = NEW.status THEN
             RAISE EXCEPTION ''Invalid status value %'', NEW.status;
       END IF;
    END IF;

    -- Check if status is a valid type.
    IF NEW.type NOTNULL THEN
       IF count(*) = 0 FROM valid_type
          where type = NEW.type THEN
             RAISE EXCEPTION ''Invalid type value %'', NEW.type;
       END IF;
    END IF;

    -- update modified field
    IF NEW.modified ISNULL THEN
       NEW.modified := ''now'';
    END IF;

    -- if modifier is not supplied, try to retrieve it from fleas_accounts
    IF NEW.modifier ISNULL THEN
      -- check if the caller exists in human_info
      v_local_user = getpgusername();
      IF v_local_user = ''fleas'' THEN
         v__id = 0;
      ELSE
         SELECT _id INTO v__id FROM fleas_human_info
         SELECT _id INTO v__id FROM fleas_human_info
           WHERE username = v_local_user
           AND _active = TRUE;
         IF NOT FOUND THEN
             RAISE EXCEPTION ''Modifier % does not exists'', v_local_user;
         END IF;
      END IF;
      NEW.modifier := v__id;
    ELSE
      -- confirm that the modifier actually exists
      SELECT _id INTO v__id FROM fleas_human_info
         WHERE username = NEW.modifier
           AND _active = TRUE;
      IF NOT FOUND THEN
         RAISE EXCEPTION ''Modifier % does not exists'', NEW.modifier;
      END IF;
    END IF;

    -- Translate the _validator field to a numeric validator
    IF NEW._validator NOTNULL THEN
       SELECT _id INTO v__id FROM fleas_human_info
          WHERE username = NEW._validator
            AND _active  = TRUE;
       IF NOT FOUND THEN
          RAISE EXCEPTION ''User account for validator % not found'',
             NEW._validator;
       END IF;
       NEW.validator := v__id;
    END IF;

    RETURN NEW;

 END;
 ' LANGUAGE 'plpgsql';

psql error message:
 pqReadData() -- backend closed the channel unexpectedly.
         This probably means the backend terminated abnormally
         before or while processing the request.
 We have lost the connection to the backend, so further processing is impossible.  Terminating.


postmaster log:        # Lengthy
 InitPostgres
 StartTransactionCommand
 ProcessUtility
 # I attempt to drop the function before I create it.
 ERROR:  RemoveFunction: function 'fleas_accounts_parse()' does not exist
 AbortCurrentTransaction
 StartTransactionCommand
 ProcessUtility
 FATAL 1:  btree: cannot split if start (2) >= maxoff (2)
 proc_exit(0) [#0]
 shmem_exit(0) [#0]
 exit(0)

`vacuum;` reported an interested message:
 fleas=> vacuum
 fleas-> ;
 NOTICE:  Rel pg_proc: Uninitialized page 22 - fixing
 VACUUM

After the vacuum, I could load the code.  _Most_ of the time,
performing a vacuum prior to loading will prevent psql from dying,
but this doesn't seem right.

Thoughts would be appreciated.  If I have neglected to include
important information (i included as much as I could), then
please reply to me ( personally or to the list ) and tell me what
info is needed.  Tnx.

tcp

В списке pgsql-general по дате отправления:

Предыдущее
От: "Tsuchiya, Mitsy"
Дата:
Сообщение: Regression test failing at crutial places.
Следующее
От: Jeff MacDonald
Дата:
Сообщение: Banner (fwd)