Thread
-
Problem with the constraints test and PRIMARY KEY on UnixWare 7.
bill.allie@mug.org — 1998-09-08T08:02:52Z
In the constraints test, a table (primary_tbl) is defined with a primary key. The table is created, shows up in the list of table using the \dt command, but does not exist if you use the \d command, or any SQL statement referencing the table. Here is the output from the \dt and \d command. regression=>\dt Database = regression +------------------+----------------------------------+----------+ | Owner | Relation | Type | +------------------+----------------------------------+----------+ [...] | postgres | path_tbl | table | | postgres | person | table | | postgres | point_tbl | table | | postgres | polygon_tbl | table | | postgres | primary_tbl | table | | postgres | real_city | table | | postgres | reltime_tbl | table | | postgres | road | table | [...] +------------------+----------------------------------+----------+ regression=> \d primary_tbl Couldn't find table primary_tbl! regression=> \di Database = regression +------------------+----------------------------------+----------+ | Owner | Relation | Type | +------------------+----------------------------------+----------+ | postgres | primary_tbl_pkey | index | | postgres | unique_tbl_i_key | index | +------------------+----------------------------------+----------+ regression=> \d primary_tbl_pkey Table = primary_tbl_pkey +----------------------------------+----------------------------+-------+ | Field | Type | Length| +----------------------------------+----------------------------+-------+ | i | int4 | 4 | +----------------------------------+----------------------------+-------+ regression=> The problem seems to be restrict to the use of PRIMARY KEY, since unique_table works fine. And here is the relavent portions from test output. QUERY: CREATE TABLE PRIMARY_TBL (i int PRIMARY KEY, t text); NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index primary_tbl_pkey for table primary_tbl QUERY: INSERT INTO PRIMARY_TBL VALUES (1, 'one'); ERROR: primary_tbl: Table does not exist. QUERY: INSERT INTO PRIMARY_TBL VALUES (2, 'two'); ERROR: primary_tbl: Table does not exist. [...] QUERY: SELECT '' AS four, * FROM PRIMARY_TBL; ERROR: primary_tbl: Table does not exist. QUERY: DROP TABLE PRIMARY_TBL; ERROR: Relation primary_tbl Does Not Exist! QUERY: CREATE TABLE PRIMARY_TBL (i int, t text, PRIMARY KEY(i,t)); NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index primary_tbl_pkey for table primary_tbl ERROR: cannot create primary_tbl QUERY: INSERT INTO PRIMARY_TBL VALUES (1, 'one'); ERROR: primary_tbl: Table does not exist. QUERY: INSERT INTO PRIMARY_TBL VALUES (2, 'two'); ERROR: primary_tbl: Table does not exist. [...] QUERY: SELECT '' AS three, * FROM PRIMARY_TBL; ERROR: primary_tbl: Table does not exist. QUERY: DROP TABLE PRIMARY_TBL; ERROR: Relation primary_tbl Does Not Exist! Any help would be appreciated. Thanks. -- ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | Compuserve: 76337,2061 |-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com |/ |LLIE | (313) 582-1540 | -
Re: [HACKERS] Problem with the constraints test and PRIMARY KEY on UnixWare 7.
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-09-08T14:30:13Z
> In the constraints test, a table (primary_tbl) is defined with a > primary key. Any help would be appreciated. Uh, yeah. This isn't a "primary key" problem, but is the same symptom we have been seeing on Linux boxes. Bruce's FreeBSD box does not exhibit the problem. It seems to involve a trashed index on the pg_class table. Do you also see a failure in the create_index regression test? afaik the problem trying to add a second index to the "onek" table is also index-related. Check the mhonarc archive for the full history, but we are still trying to get a handle on it and would welcome any help. There also is a problem with views/rules on the Linux boxes (at least, some problems clearly span multiple platforms but no problems appear on all platforms); do you see a failure when doing "select * from pg_user" on a clean installation? - Tom -
Re: [HACKERS] Problem with the constraints test and PRIMARY KEY on UnixWare 7.
David Hartwig <daveh@insightdist.com> — 1998-09-08T14:41:54Z
This is the same problem as that has been pestering me for two weeks. Billy, please try this simple test: CREATE TABLE foo (bar int); \d foo CREATE INDEX foo_idx ON foo USING btree (bar); \d foo Is foo gone? Billy G. Allie wrote: > In the constraints test, a table (primary_tbl) is defined with a primary key. > The table is created, shows up in the list of table using the \dt command, but > does not exist if you use the \d command, or any SQL statement referencing the > table. Here is the output from the \dt and \d command. > > regression=>\dt > > Database = regression > +------------------+----------------------------------+----------+ > | Owner | Relation | Type | > +------------------+----------------------------------+----------+ > [...] > | postgres | path_tbl | table | > | postgres | person | table | > | postgres | point_tbl | table | > | postgres | polygon_tbl | table | > | postgres | primary_tbl | table | > | postgres | real_city | table | > | postgres | reltime_tbl | table | > | postgres | road | table | > [...] > +------------------+----------------------------------+----------+ > regression=> \d primary_tbl > Couldn't find table primary_tbl! > regression=> \di > > Database = regression > +------------------+----------------------------------+----------+ > | Owner | Relation | Type | > +------------------+----------------------------------+----------+ > | postgres | primary_tbl_pkey | index | > | postgres | unique_tbl_i_key | index | > +------------------+----------------------------------+----------+ > regression=> \d primary_tbl_pkey > > Table = primary_tbl_pkey > +----------------------------------+----------------------------+-------+ > | Field | Type | Length| > +----------------------------------+----------------------------+-------+ > | i | int4 | 4 | > +----------------------------------+----------------------------+-------+ > regression=> > > The problem seems to be restrict to the use of PRIMARY KEY, since unique_table > works fine. > > And here is the relavent portions from test output. > > QUERY: CREATE TABLE PRIMARY_TBL (i int PRIMARY KEY, t text); > NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index > primary_tbl_pkey for table primary_tbl > QUERY: INSERT INTO PRIMARY_TBL VALUES (1, 'one'); > ERROR: primary_tbl: Table does not exist. > QUERY: INSERT INTO PRIMARY_TBL VALUES (2, 'two'); > ERROR: primary_tbl: Table does not exist. > [...] > QUERY: SELECT '' AS four, * FROM PRIMARY_TBL; > ERROR: primary_tbl: Table does not exist. > QUERY: DROP TABLE PRIMARY_TBL; > ERROR: Relation primary_tbl Does Not Exist! > QUERY: CREATE TABLE PRIMARY_TBL (i int, t text, PRIMARY KEY(i,t)); > NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index > primary_tbl_pkey for table primary_tbl > ERROR: cannot create primary_tbl > QUERY: INSERT INTO PRIMARY_TBL VALUES (1, 'one'); > ERROR: primary_tbl: Table does not exist. > QUERY: INSERT INTO PRIMARY_TBL VALUES (2, 'two'); > ERROR: primary_tbl: Table does not exist. > [...] > QUERY: SELECT '' AS three, * FROM PRIMARY_TBL; > ERROR: primary_tbl: Table does not exist. > QUERY: DROP TABLE PRIMARY_TBL; > ERROR: Relation primary_tbl Does Not Exist! > > Any help would be appreciated. > Thanks. > -- > ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org > | /| | 7436 Hartwell | Compuserve: 76337,2061 > |-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com > |/ |LLIE | (313) 582-1540 |
-
Re: [HACKERS] Problem with the constraints test and PRIMARY KEY on UnixWare 7.
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-09-08T16:44:02Z
> This is the same problem as that has been pestering me for two weeks. Just a reminder: you aren't the only one :/ > Billy, please try this simple test: > CREATE TABLE foo (bar int); > \d foo > CREATE INDEX foo_idx ON foo USING btree (bar); > \d foo > Is foo gone? Depending on the outcome, you will fall into one of three camps wrt indexing problems: 1) no problem, no matter what test you run (Bruce and FreeBSD) 2) problems at some level, but needing a slightly more complicated sequence of commands to get there (Tom, Tatsuo, and Linux, etc.) 3) problems with a very simple sequence of commands (David and AIX) Assuming that these all stem from a single underlying problem, then it seems that David's machine would have the fast-track on finding it, since he can provoke symptoms so easily. Unfortunately, none of those affected with the problem are familiar with the areas of code which are problematic. Does anyone else see the problem at David's level? Does anyone see these problems on anything other than Linux and Unixware? Does anyone see no problems on anything other than FreeBSD? There is another problem in the code wrt views and rules and freeing memory after a query. I'm starting to look at that one, figuring that it will be easier to track down and will reduce the number of problems we are trying to fight at one time. - Tom -
Re: [HACKERS] Problem with the constraints test and PRIMARY KEY on UnixWare 7.
David Hartwig <daveh@insightdist.com> — 1998-09-08T17:32:20Z
Thomas G. Lockhart wrote: > > This is the same problem as that has been pestering me for two weeks. > > Just a reminder: you aren't the only one :/ > > > Billy, please try this simple test: > > CREATE TABLE foo (bar int); > > \d foo > > CREATE INDEX foo_idx ON foo USING btree (bar); > > \d foo > > Is foo gone? > > Depending on the outcome, you will fall into one of three camps wrt > indexing problems: > 1) no problem, no matter what test you run (Bruce and FreeBSD) > 2) problems at some level, but needing a slightly more complicated > sequence of commands to get there (Tom, Tatsuo, and Linux, etc.) > 3) problems with a very simple sequence of commands (David and AIX) > > Assuming that these all stem from a single underlying problem, then it > seems that David's machine would have the fast-track on finding it, > since he can provoke symptoms so easily. Unfortunately, none of those > affected with the problem are familiar with the areas of code which are > problematic. > > Does anyone else see the problem at David's level? Does anyone see these > problems on anything other than Linux and Unixware? Does anyone see no > problems on anything other than FreeBSD? > > There is another problem in the code wrt views and rules and freeing > memory after a query. I'm starting to look at that one, figuring that it > will be easier to track down and will reduce the number of problems we > are trying to fight at one time. > > - Tom
-
Indixing problems...
Vadim Mikheev <vadim@krs.ru> — 1998-09-09T03:21:05Z
David Hartwig wrote: > > This is the same problem as that has been pestering me for two weeks. > > Billy, please try this simple test: > > CREATE TABLE foo (bar int); > > \d foo > > CREATE INDEX foo_idx ON foo USING btree (bar); > > \d foo > > Is foo gone? Please apply this patch... Vadim
-
Re: [HACKERS] Indixing problems...
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-09-09T04:25:30Z
> David Hartwig wrote: > > > > This is the same problem as that has been pestering me for two weeks. > > > > Billy, please try this simple test: > > > > CREATE TABLE foo (bar int); > > > > \d foo > > > > CREATE INDEX foo_idx ON foo USING btree (bar); > > > > \d foo > > > > Is foo gone? > > Please apply this patch... > > Vadim > *** src/backend/catalog/index.c.orig Wed Sep 9 11:14:40 1998 > --- src/backend/catalog/index.c Wed Sep 9 11:15:50 1998 > *************** > *** 1424,1433 **** > > newtup = heap_modifytuple(tuple, pg_class, values, nulls, replace); > heap_replace(pg_class, &tuple->t_ctid, newtup); > - pfree(newtup); > CatalogOpenIndices(Num_pg_class_indices, Name_pg_class_indices, idescs); > CatalogIndexInsert(idescs, Num_pg_class_indices, pg_class, newtup); > CatalogCloseIndices(Num_pg_class_indices, idescs); > } > > if (!IsBootstrapProcessingMode()) > --- 1424,1433 ---- > > newtup = heap_modifytuple(tuple, pg_class, values, nulls, replace); > heap_replace(pg_class, &tuple->t_ctid, newtup); > CatalogOpenIndices(Num_pg_class_indices, Name_pg_class_indices, idescs); > CatalogIndexInsert(idescs, Num_pg_class_indices, pg_class, newtup); > CatalogCloseIndices(Num_pg_class_indices, idescs); > + pfree(newtup); > } > > if (!IsBootstrapProcessingMode()) Wow, this is GREAT. Vadim saves me AGAIN. I did write this code as part of the megpatch, because tuple allocations where not being properly de-allocated. This clearly is a bug, and hopefully it will be the fix I have been looking for. I was supposed to get on David Hartwig's AIX machine tomorrow, so if this fixes all our problems, we can move on to more productive items. Again, sorry to have introduced this bug into the code, and thanks again to Vadim for finding it. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
-
Re: [HACKERS] Indixing problems...
David Hartwig <daveh@insightdist.com> — 1998-09-09T12:46:28Z
Life is good once more. :-) Thanks Vadim Vadim Mikheev wrote: > Please apply this patch... > > Vadim