Thread: ESTERROR
ESTERROR: relation with OID 75872 does not exist What does ESTERROR stand for? I'm seeing my log files fill up with these errors. Version: PostgreSQL 8.1.2 on sparc-sun-solaris2.8, compiled by /opt/spro62/SUNWspro/bin/cc -Xa
On Tue, Mar 14, 2006 at 04:05:06PM -0500, Michael Guerin wrote: > ESTERROR: relation with OID 75872 does not exist > > What does ESTERROR stand for? I'm seeing my log files fill up with > these errors. "EST" looks suspiciously like "Eastern Standard Time," considering that the timezone in your email is -0500. Does a timestamp immediately precede the above string? Have you set log_line_prefix without a trailing space? As for "relation with OID X does not exist," see if the FAQ's explanation fits your situation: http://www.postgresql.org/docs/faqs.FAQ.html#item4.19 -- Michael Fuhr
Michael Guerin wrote: > ESTERROR: relation with OID 75872 does not exist > > What does ESTERROR stand for? I'm seeing my log files fill up with > these errors. > > Version: > PostgreSQL 8.1.2 on sparc-sun-solaris2.8, compiled by > /opt/spro62/SUNWspro/bin/cc -Xa > Please ignore the question about ESTERROR, guess I stayed out too late last night.. :( Although, how should I try to track down these ERROR: relation with OID 75872 does not exist messages? -Michael
> "EST" looks suspiciously like "Eastern Standard Time," considering > that the timezone in your email is -0500. Does a timestamp immediately > precede the above string? Have you set log_line_prefix without a > trailing space? > Yep, its East Std. Time.. I've already awarded myself the DA award for today... :( > As for "relation with OID X does not exist," see if the FAQ's > explanation fits your situation: > > http://www.postgresql.org/docs/faqs.FAQ.html#item4.19 > No, no temp tables are used in any of our functions. It seems to have gone away after I stopped and restarted the database. Here's a little background on the db that was having this problem. The database is not typical, its created using files and tables are basically dropped and recreated every time one of the source files change. Temp tables are created and populated then within a transaction the live table is dropped and the tmp table is renamed to be the live table. thanks -mike
Looks like my problem is back again today: ERROR: relation with OID 76511 does not exist What's the best way to track down this issue? Also, when I see these errors there's usually no active query, maybe stat's collector or some other internal process is looking for a table that doesn't exist anymore? -Mike Michael Guerin wrote: > >> "EST" looks suspiciously like "Eastern Standard Time," considering >> that the timezone in your email is -0500. Does a timestamp immediately >> precede the above string? Have you set log_line_prefix without a >> trailing space? >> > > Yep, its East Std. Time.. I've already awarded myself the DA award for > today... :( > >> As for "relation with OID X does not exist," see if the FAQ's >> explanation fits your situation: >> >> http://www.postgresql.org/docs/faqs.FAQ.html#item4.19 >> > No, no temp tables are used in any of our functions. It seems to have > gone away after I stopped and restarted the database. > Here's a little background on the db that was having this problem. > The database is not typical, its created using files and tables are > basically dropped and recreated every time one of the source files > change. Temp tables are created and populated then within a > transaction the live table is dropped and the tmp table is renamed to > be the live table. > thanks > -mike >
Michael Guerin <guerin@rentec.com> writes: > Looks like my problem is back again today: > ERROR: relation with OID 76511 does not exist > What's the best way to track down this issue? Is it always the same OID mentioned in the errors, or are they variable? If always the same, my first thought would be a corrupt entry in the system catalogs --- try looking for occurrences of that value in the catalog columns that link to pg_class.oid, such as pg_index.indexrelid. The system catalogs documentation for your PG version will show you which columns to look at exactly --- see http://www.postgresql.org/docs/8.1/static/catalogs.html (adjust in the obvious way for your version) regards, tom lane
Is the autovacuum running? Prolly related tho. g.- On 3/15/06, Michael Guerin <guerin@rentec.com> wrote: > Looks like my problem is back again today: > > ERROR: relation with OID 76511 does not exist > > What's the best way to track down this issue? Also, when I see these > errors there's usually no active query, maybe stat's collector or some > other internal process is looking for a table that doesn't exist anymore? > > -Mike > > > > Michael Guerin wrote: > > > >> "EST" looks suspiciously like "Eastern Standard Time," considering > >> that the timezone in your email is -0500. Does a timestamp immediately > >> precede the above string? Have you set log_line_prefix without a > >> trailing space? > >> > > > > Yep, its East Std. Time.. I've already awarded myself the DA award for > > today... :( > > > >> As for "relation with OID X does not exist," see if the FAQ's > >> explanation fits your situation: > >> > >> http://www.postgresql.org/docs/faqs.FAQ.html#item4.19 > >> > > No, no temp tables are used in any of our functions. It seems to have > > gone away after I stopped and restarted the database. > > Here's a little background on the db that was having this problem. > > The database is not typical, its created using files and tables are > > basically dropped and recreated every time one of the source files > > change. Temp tables are created and populated then within a > > transaction the live table is dropped and the tmp table is renamed to > > be the live table. > > thanks > > -mike > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings > -- Guido Barosio -----------------------
Tom Lane wrote: > Michael Guerin <guerin@rentec.com> writes: > >> Looks like my problem is back again today: >> ERROR: relation with OID 76511 does not exist >> What's the best way to track down this issue? >> > > 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. I've since restarted and haven't seen the error, but I suspect I'll see it again later today. > If always the same, my first thought would be a corrupt entry in the > system catalogs --- try looking for occurrences of that value in the > catalog columns that link to pg_class.oid, such as pg_index.indexrelid. > The system catalogs documentation for your PG version will show you > which columns to look at exactly --- see > http://www.postgresql.org/docs/8.1/static/catalogs.html > (adjust in the obvious way for your version) > will do. > regards, tom lane >
Guido Barosio wrote: > Is the autovacuum running? > Prolly related tho. > No, autovac is not turned on, its not needed b/c the information in the database is static. If data needs to be changed, the new data is inserted into a temp table, indexes are created, vacuumed, then the old table is dropped and the temp table is renamed. Sounds ugly, but its actually a good solution for the constraints we have. -mike
Michael Guerin <guerin@rentec.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
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@rentec.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
>