Обсуждение: Sequence nexvtal() and initdb/pg_proc problem
CVS as of right now (18:40 pm Central), I can't make(use) sequences, and initdb puts part of pg_proc in the wrong place. Redhat Linux 6.0 Linux 2.2.7 glibc 2.1 (SQL below directly from a pg_dump -z): \connect - postgres 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 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 -rw------- 1 postgres postgres 131072 May 22 18:38 data/base/template1/pg_proc -rw------- 1 postgres postgres 8192 May 22 18:40 data/base/template1/pg_proc.1 -rw------- 1 postgres postgres 40960 May 22 18:40 data/base/template1/pg_proc_oid_index -rw------- 1 postgres postgres 131072 May 22 18:40 data/base/template1/pg_proc_proname_narg_type_index -rw------- 1 postgres postgres 57344 May 22 18:40 data/base/template1/pg_proc_prosrc_index -rw------- 1 postgres postgres 40960 May 22 18:38 pg_proc.1 -rw------- 1 postgres postgres 8192 May 22 18:38 pg_proc_proname_narg_type_index.1 Thanks, Ole Gjerde
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
On Sun, 23 May 1999, Tom Lane wrote: [snip - nextval problem] > Can't duplicate that here --- but it might well be related to your > busted pg_proc table ... Indeed that was the problem. > 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. Yes, I removed one too many 0's from RELSEG_SIZE to do some testing. I usually set it to 0x200000 / BLCKSZ for testing segment related things. > 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... It's definately not worth the time right now. I will probably take a look at this in couple of weeks, since it probably should be checked. Thanks, Ole Gjerde