database error xx000?
I am doing a ton of pgsql over here defining and redefining functions and
triggers and every day or so I get this:
Error: Database error XX000: cache lookup failed for type 5276542
Query: select dcm.task_user_dispos(42895::bigint, 870::bigint)
[condition type: internal-error]
If I exit everything and start over (but not bouncing the PG server) the
problem goes away.
I gather this kind of DB error is not a user error, but I would still be
interested in learning how to avoid it because even in production we will
need to be redefining functions periodically.
Does the above give anyone any ideas at all about what is going on?
Environemnt is:
Version string PostgreSQL 9.1.2 on x86_64-unknown-linux-gnu, compiled by
gcc (GCC) 4.4.5 20110214 (Red Hat 4.4.5-6), 64-bit
Thx, ken
Kenneth Tilton <ktilton@mcna.net> writes:
I am doing a ton of pgsql over here defining and redefining functions and
triggers and every day or so I get this:
Error: Database error XX000: cache lookup failed for type 5276542
Does the above give anyone any ideas at all about what is going on?
No. Can you produce a self-contained test case?
regards, tom lane
On Thu, Apr 26, 2012 at 2:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Kenneth Tilton <ktilton@mcna.net> writes:
I am doing a ton of pgsql over here defining and redefining functions and
triggers and every day or so I get this:Error: Database error XX000: cache lookup failed for type 5276542
Does the above give anyone any ideas at all about what is going on?
No.
:) What is "type 5276542"? Does not look like much of a type.
And why is a cache lookup an error? If it is not in the cache go find the
definition! :)
I guess it "knows" something should be in the cache and then does not find
it. Prolly that code needs to be taught about the possibility of things
being redefined so it goes out and finds the function by name. Of course if
it threw away the name and kept only a cache pointer...well, then it needs
to stop throwing away the name.
Can you produce a self-contained test case?
I doubt it. Every test iteration I run includes a lot of redefining of
functions and triggers all over the map, and it works fine thru dozens of
iterations. The wheels seem to come off after a serious refactoring.
Nothing is needed to clear the problem except (it seems) close any
connections to the DB, so I guess some optimization does not work in the
face of sufficient dynamic redefinition.
-kt
On Thu, Apr 26, 2012 at 1:59 PM, Kenneth Tilton <ktilton@mcna.net> wrote:
On Thu, Apr 26, 2012 at 2:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Can you produce a self-contained test case?
I doubt it. Every test iteration I run includes a lot of redefining of
functions and triggers all over the map, and it works fine thru dozens of
iterations. The wheels seem to come off after a serious refactoring.
Nothing is needed to clear the problem except (it seems) close any
connections to the DB, so I guess some optimization does not work in the
face of sufficient dynamic redefinition.
Suggestion: create a program which attempts to stress-test Postgresql by
doing similar things. Even if a single test case does not reliably
reproduce the issue, a stress-test might trigger the condition after some
time.
On Thu, Apr 26, 2012 at 3:07 PM, dennis jenkins <dennis.jenkins.75@gmail.com
wrote:
On Thu, Apr 26, 2012 at 1:59 PM, Kenneth Tilton <ktilton@mcna.net> wrote:
On Thu, Apr 26, 2012 at 2:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Can you produce a self-contained test case?
I doubt it. Every test iteration I run includes a lot of redefining of
functions and triggers all over the map, and it works fine thru dozens of
iterations. The wheels seem to come off after a serious refactoring.
Nothing is needed to clear the problem except (it seems) close any
connections to the DB, so I guess some optimization does not work in the
face of sufficient dynamic redefinition.Suggestion: create a program which attempts to stress-test Postgresql by
doing similar things. Even if a single test case does not reliably
reproduce the issue, a stress-test might trigger the condition after some
time.
I am starting to suspect this does it (having reproduced the problem with
vastly less effort than suspected): with function A calling function B, and
function B coming in several variants (diff params), drop then define A and
then drop/define only one variant of B. Order there may not matter.
I plan anyway to enhance our builder so it knows about function overloading
and rebuilds all variants when it rebuilds one. If the problem goes away
I'll take a crack at creating a reproducible.
Thx for the feedback.
-ken