Re: [HACKERS] Sequence nexvtal() and initdb/pg_proc problem

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Sequence nexvtal() and initdb/pg_proc problem
Дата
Msg-id 27897.927497774@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Sequence nexvtal() and initdb/pg_proc problem  (Ole Gjerde <gjerde@icebox.org>)
Ответы Re: [HACKERS] Sequence nexvtal() and initdb/pg_proc problem  (Ole Gjerde <gjerde@icebox.org>)
Список pgsql-hackers
Ole Gjerde <gjerde@icebox.org> writes:
> CREATE SEQUENCE "cagedata_id_seq" start 165437 increment 1 maxvalue 2147483647 minvalue 1  cache 1 ;
> SELECT nextval ('cagedata_id_seq');
> ERROR:  No such function 'nextval' with the specified attributes

Can't duplicate that here --- but it might well be related to your
busted pg_proc table ...

> I also just ran initdb on a clean install, and pg_proc.1 and
> pg_proc_proname_narg_type_index.1 gets put in /home/postgres as well as in
> /home/postgres/data/base/template1

Hmm, it sounds like something is being sloppy about attaching the full
database path to the names of relation extension files.  During normal
backend operation, the backend is cd'd into the database directory,
so it doesn't really matter whether you prepend the path or not.
But evidently that's not always true during initdb.  You must be running
with a very low value of RELSEG_SIZE to have precipitated such a
problem, however.

Reasonable fixes would be either to force the appropriate cd during
initdb, or to find and fix the place that's touching extension segments
using a relative pathname.  But I can't get excited about spending much
time on it, since the problem will never arise at realistic RELSEG_SIZE
settings...
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Partial fix for INSERT...SELECT problems
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] DEFAULT fixed