Re: ESTERROR

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 |
127.0.0.1 | 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
>