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

Re: Rare corruption of pg_class index

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Greg Sabino Mullane <greg(at)turnstep(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Rare corruption of pg_class index
Date: 2006-12-20 18:21:57
Message-ID: 1166638917.24294.41.camel@dogma.v10.wvs (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, 2006-12-20 at 18:06 +0000, Greg Sabino Mullane wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> I'm encountering some disconcerting problems on a 8.1.3 database.
> Very occasionally, I get a "could not open relation with OID xxx".
> This always occurs inside of a plpgsql function, and always refers
> to a normal, stable table that has not been dropped. The first
> time this occured, I reindexed the system indexes, but it has occured
> again, and on more than one database, which seems to lessen the chance
> of a hardware issue or a temporary index corruption issue. The functions
> in question are called many times, but the error only happens once in
> a blue moon. The last time it happened, the function ran with no problem
> one minute before the error, and again four minutes afterwards. The
> table name is hard-coded into the functions. This happens on average
> five times a day or so, on a very busy database (> 10M statements/day,
> the functions fire tens of thousands of times)
> 

It has to do with PL/pgSQL caching the plans of the statements inside.
If there is some kind of change that causes that plan to become invalid,
that could cause that error.

You can almost certainly fix it by using EXECUTE in the function, which
will not cache the plan, or telling all clients to reconnect when you
make a change that could invalidate the plan.

Regards,
	Jeff Davis


In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2006-12-20 18:27:29
Subject: Re: Rare corruption of pg_class index
Previous:From: Greg Sabino MullaneDate: 2006-12-20 18:06:29
Subject: Rare corruption of pg_class index

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