Skip site navigation (1) Skip section navigation (2)


From: Michael Guerin <guerin(at)rentec(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: ESTERROR
Date: 2006-03-16 22:00:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-novice
Hi Tom,

    I believe the following may be happening although I can't prove it 
yet.  An application holds a persistent connection on the database and 
creates a number of prepared statements.  Sometime during the day tables 
are dropped and recreated with new data.  Is it possible that the query 
plan for this statement is still referencing the original table oid, so 
when it looks up the plan it finds that the oid doesn't exists any more 
and complains?    It seems to have something to do with prepared 
statements b/c the only sql I see when this is happening is a <BIND>.

pid 431 is the id in the log associated with all my errors.

commonsym=# select * from pg_stat_activity ;
 datid |  datname  | procpid | usesysid |  usename  | current_query 
|          query_start          |         backend_start         | 
client_addr  | client_port
 16384 | commonsym |     431 |    16385 | commonsym | <BIND>        | 
2006-03-16 15:23:26.928458-05 | 2006-03-16 10:22:04.986391-05 |    |       36110
(5 rows)

Tom Lane wrote:
> Michael Guerin <guerin(at)rentec(dot)com> writes:
>> Tom Lane wrote:
>>> Is it always the same OID mentioned in the errors, or are they variable?
>> It was the same OID, until I restarted then it changed to a new OID.  
> Hmm, that sure sounds like a plan-caching problem.  One thing you should
> do is modify log_line_prefix so you can tell which process the error is
> coming from ... then you'd have a better shot at telling what's causing
> it.
> 			regards, tom lane

In response to

pgsql-novice by date

Next:From: Richard Broersma JrDate: 2006-03-17 01:45:56
Subject: Alter View foo?
Previous:From: operationsengineer1Date: 2006-03-16 21:10:02
Subject: Re: Find and Replace All

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group