Thread
-
SQL update statements are dying in the query planner
Panon, Paul-Andre <paul-andrepanon@sierrasystems.com> — 2001-05-24T00:03:14Z
============================================================================ POSTGRESQL BUG REPORT TEMPLATE ============================================================================ Your name : Your email address : System Configuration --------------------- Architecture (example: Intel Pentium) : Intel Pentium Pro Operating System (example: Linux 2.0.26 ELF) :Mandrake Linux 7.2 Kernel 2.2.17-21mdksmp PostgreSQL version (example: PostgreSQL-7.1.1): PostgreSQL-7.1.1 Compiler used (example: gcc 2.95.2) :gcc version 2.95.3 19991030 (prerelease) Please enter a FULL description of your problem: ------------------------------------------------ SQL update statements are dying in the query planner. A copy of the -d3 postgres log is attached. The error returned by psql when submitting this query is ERROR: Relation 2699531655 does not exist however a very similar statement was successfully executed shortly before the failing statement. I am using a custom GUID/UUID data type extension similar to the MS SQL Server uniqueidentifier data type. I used the varbits type in the contrib directory as a template, as well as the FreeDCE library to generate new UUIDs. I would be happy to contribute this code if anybody is interested. With the new ODBC driver working towards ODBC 3.0 level support, there may be more interest in having GUID support in PostgreSQL. Although I can't rule out that the UUID data type may be at fault, it does work correctly under 7.0.2 . Unfortunately I cannot provide a copy of the data beyond what is in the actual SQL statement, though I could probably provide a copy of the schema for the relevant SQL tables if it would help. ---------------------------------------------------------------------- Perhaps this may be related to another bug that Tom Lane describes as: The direct cause of the problem is that EvalPlanQual isn't completely initializing the estate that it sets up for re-evaluating the plan. In particular it's not filling in es_result_relations and es_num_result_relations, which need to be set up if the top plan node is an Append. since psql refers to a vary large relation oid in its error message? It looks like the query is crashing after the query parsing is completed. -d4 doesn't seem to provide additional useful information regarding the Query Processing and where it is breaking. If there are any additional flags at compile or run time that I can set to provide more useful information, please let me know. --------------------------------------------------------------------- <<postgresql.log>> Paul-Andre Panon Sierra Systems 1177 West Hastings Street, Suite 2500 Vancouver, BC V6E 2K3 Main: 604.688.1371 Fax: 604.688.6482 www.SierraSystems.com