Re: Relation 0 does not exist - Mailing list pgsql-general
From | Patrick Welche |
---|---|
Subject | Re: Relation 0 does not exist |
Date | |
Msg-id | 20020925222949.E9603@quartz.newn.cam.ac.uk Whole thread Raw |
In response to | Re: Relation 0 does not exist (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Relation 0 does not exist
|
List | pgsql-general |
On Wed, Sep 25, 2002 at 04:52:30PM -0400, Tom Lane wrote: > Patrick Welche <prlw1@newn.cam.ac.uk> writes: > > The subject says it all: > > ERROR: Relation 0 does not exist > > LOG: statement: INSERT INTO trans (meter_id,stats_id,flowindex,firsttime,firstt... > > Could we see the *whole* query? And the schemas of the table(s) it > uses? Seems like a bug to me, but without enough context to reproduce > it I can't do much. DEBUG: StartTransactionCommand DEBUG: ProcessQuery ERROR: Relation 0 does not exist LOG: statement: INSERT INTO trans (meter_id,stats_id,flowindex,firsttime,firsttimed,firsttimet,firsttimei,lasttime,lasttimed,lasttimet,lasttimei,sourcepeeraddress,sourcepeername,sourcetransaddress,destpeeraddress,desttransaddress,sourcetranstype,frompdus,fromoctets,topdus,tooctets,deltafromoctets,deltatooctets) VALUES(411, currval('stats_id_seq'),5,'08:52:11 Mon 22 Jul 2002'::timestamp without time zone+'5536695.89 second',('08:52:11Mon 22 Jul 2002'::timestamp without time zone+'5536695.89 second')::date,('08:52:11 Mon 22 Jul 2002'::timestampwithout time zone+'5536695.89 second')::time,553669589,'08:52:11 Mon 22 Jul 2002'::timestamp without timezone+'5660731.53 second',('08:52:11 Mon 22 Jul 2002'::timestamp without time zone+'5660731.53 second')::date,('08:52:11Mon 22 Jul 2002'::timestamp without time zone+'5660731.53 second')::time,566073153,'192.168.3.4','hostname.here.ac.uk',2,'192.168.3.2',53,17,14403,5271978,14419,1226291,507098::bigint,109306::bigint) DEBUG: AbortCurrentTransaction LOG: pq_recvbuf: unexpected EOF on client connection DEBUG: proc_exit(0) One thing which bugs me: I have a currval in there, and that is the very first query which reaches the database, so it won't be "set", will it, but then, how could it have worked for months with the other version of server? (Source files are old - recompiled just in case postgres header files changed) Hmm then it would have complained about Relation "stats_id_seq" no? Table "public.trans" Column | Type | Modifiers --------------------+--------------------------------+----------- meter_id | integer | stats_id | integer | flowindex | integer | firsttime | timestamp(6) without time zone | firsttimed | date | firsttimet | time(0) without time zone | firsttimei | integer | lasttime | timestamp(6) without time zone | lasttimet | time(0) without time zone | lasttimed | date | lasttimei | integer | sourcepeeraddress | inet | sourcepeername | text | sourcetransaddress | integer | destpeeraddress | inet | destpeername | text | desttransaddress | integer | sourcetranstype | integer | frompdus | integer | fromoctets | integer | topdus | integer | tooctets | integer | deltafromoctets | bigint | deltatooctets | bigint | dpndate | date | nettype | integer | Indexes: firsttimei_idx btree (firsttimei), srcpeername_idx btree (sourcepeername) Triggers: RI_ConstraintTrigger_14413070, RI_ConstraintTrigger_14413073 Cheers, Patrick
pgsql-general by date: