call f
... somebody updates f's pg_proc tuple
... recursively call f
At this point PLy_procedure_get will decide the cache entry is obsolete
and happily trash the procedure data that the outer call is still using.
We ran into this long ago with plpgsql
Andres Freund writes:
> On 2013-01-25 17:07:59 -0500, Tom Lane wrote:
>> Neither version of gcc I tried complained about this, and I assume yours
>> didn't either, which is a bit annoying/scary. I wonder whether the
>> "volatile" marker prevents that?
> I think the control flow is just to comple
On 2013-01-25 17:07:59 -0500, Tom Lane wrote:
> Andres Freund writes:
> > The bug got introduced in 46211da1b84bc3537e799ee1126098e71c2428e8 which
> > interestingly says "Using HTABs instead of Python dictionaries makes
> > error recovery easier, and allows for procedures to be cached based on
> >
Andres Freund writes:
> The bug got introduced in 46211da1b84bc3537e799ee1126098e71c2428e8 which
> interestingly says "Using HTABs instead of Python dictionaries makes
> error recovery easier, and allows for procedures to be cached based on
> their OIDs, not their names." - but the caching seems t
On 2013-01-25 15:40:46 -0500, Tom Lane wrote:
> Andres Freund writes:
> > quite possibly doesn't work if copied from here but for quicker viewing:
>
> > CREATE OR REPLACE FUNCTION "foo():
> > pass
>
> > import os
> > os._exit(1)
> > def "() RETURNS void LANGUAGE plpythonu AS $$pass$$;
>
> >
Andres Freund writes:
> quite possibly doesn't work if copied from here but for quicker viewing:
> CREATE OR REPLACE FUNCTION "foo():
> pass
> import os
> os._exit(1)
> def "() RETURNS void LANGUAGE plpythonu AS $$pass$$;
> Yep:
> LOG: server process (PID 29317) exited with exit code 1
On 2013-01-25 21:07:51 +0100, Andres Freund wrote:
> On 2013-01-25 14:51:39 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > Its slightly more complex than just making it one hash table with an
> > > extended key. When validating a trigger function we don't have a
> > > relation to do the ca
On 2013-01-25 14:51:39 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Its slightly more complex than just making it one hash table with an
> > extended key. When validating a trigger function we don't have a
> > relation to do the cache lookup. I chose to handle that case by not
> > doing a ca
Andres Freund writes:
> Its slightly more complex than just making it one hash table with an
> extended key. When validating a trigger function we don't have a
> relation to do the cache lookup. I chose to handle that case by not
> doing a cache lookup at all in that case which imo is a sensible
>
On 2013-01-24 11:40:33 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-24 15:03:36 +0100, Sandro Santilli wrote:
> > ISTM the caching code for plpythonu trigger functions has been broken
> > for some time. The bug seem to be that PLy_procedure_get looks up the
> > function in a separ
Andres Freund writes:
> Tom, any other committer: I am happy to provide a <= 9.1 version of the
> patch because plpython has been noticeably restructured in 9.1=>9.2, but
> I am not sure if that helps you at all.
We need to back-patch to any branch where this is broken. If the patch
would change
On 2013-01-24 11:40:33 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-24 15:03:36 +0100, Sandro Santilli wrote:
> > ISTM the caching code for plpythonu trigger functions has been broken
> > for some time. The bug seem to be that PLy_procedure_get looks up the
> > function in a separ
Andres Freund writes:
> On 2013-01-24 15:03:36 +0100, Sandro Santilli wrote:
> ISTM the caching code for plpythonu trigger functions has been broken
> for some time. The bug seem to be that PLy_procedure_get looks up the
> function in a separate cache for trigger functions (PLy_trigger_cache)
> bu
On 2013-01-24 15:03:36 +0100, Sandro Santilli wrote:
> I've found a bug in plpythonu resulting in a "cache lookup" failure.
> Here's the SQL to reproduce (thanks Andres):
>
> CREATE EXTENSION plpythonu;
> CREATE OR REPLACE FUNCTION t() RETURNS trigger AS 'pass' LANGUAGE
> 'plpythonu';
> CREATE
I've found a bug in plpythonu resulting in a "cache lookup" failure.
Here's the SQL to reproduce (thanks Andres):
CREATE EXTENSION plpythonu;
CREATE OR REPLACE FUNCTION t() RETURNS trigger AS 'pass' LANGUAGE 'plpythonu';
CREATE TABLE a();
CREATE TABLE b();
CREATE TRIGGER check_quota AFTER INS
"Sivaraman K.G" <[EMAIL PROTECTED]> writes:
> \d command used to give the existing relations in the database.
> But now it is saying :
> ERROR : Cache lookup failed for relation 17233.
Not a lot of information to go on here. What do you get from
select * from pg_class where oid = 17233;
Can you
Hi all,
I have the following problem in my testbed :
PostgreSQL version: 8.0
Operating system: Solaris 8.0
Description: Cache lookup failed.
I am running PostgreSQL ver. 8.0 with table space setup'ed for
CTBLISTDB.
\d command used to give the existing relations in the database.
But now i
I have a next problem
ERROR: fmgr_info: function 16556:
cache lookup failed
Nicolas Alberto Recab
18 matches
Mail list logo
