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
15 matches
Mail list logo
