Re: Vacuum causing stange changes in DB

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: andrew(at)ernie(dot)2sheds(dot)de
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Vacuum causing stange changes in DB
Date: 2001-01-16 01:49:20
Message-ID: 29594.979609760@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

andrew(at)ernie(dot)2sheds(dot)de writes:
> I have a perl script which inserts records based on certain
> critera. I have noticed that if I do a vacuum WHILE my script
> is running, that I get a message:
> DBD::Pg::st execute failed: ERROR: Unable to locate type oid 150 in catalog

Hmm ... considering that OID 150 is not a type at all (it's the function
int4ge), this would seem to indicate that garbage data is being picked
up and fed to a catalog lookup. I suspect that what you are seeing is
an example of the infamous catalog-cache-entry-dropped-while-in-use
problem, and that the intended type-OID value is being picked up from a
catalog cache row that isn't there anymore due to vacuum having forced
it to be invalidated.

How reproducible is the behavior --- do you get an error consistently,
or only sometimes? Do you always see exactly this same message, or does
it vary? The less reproducible it is, the more I'd tend to think it's
the entry-drop bug.

The bug is fixed (at long last) for 7.1, but in prior versions the only
good workaround is not to vacuum system tables while there are other
active backends.

regards, tom lane

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Ian Harding 2001-01-16 04:51:56 Re: date/time
Previous Message andrew 2001-01-16 01:33:54 Vacuum causing stange changes in DB