Обсуждение: 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 5276542Query: 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