From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | Victor Wagner <vitus(at)wagner(dot)pp(dot)ru>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Convert pltcl from strings to objects |
Date: | 2016-02-25 15:30:33 |
Message-ID: | 20160225153032.GA6509@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jim Nasby wrote:
> >Here we have another case. prodesc is a global thing. And it is shared
> >between different operations. Problem was that there is no partcular
> >owner, and we have to wait when last operation which deals with it
> >would finish. It looks like perfect job for reference counting.
>
> I've just tried to wrap my head around what's going on with prodesc and
> failed... specifically, I don't understand this claim in the comment:
>
> * Add the proc description block to the hashtable. Note we do not
> * attempt to free any previously existing prodesc block. !!This is
> * annoying, but necessary since there could be active calls using
> * the old prodesc.!!
>
> What else could be referencing it? I realize it's stored in pltcl_proc_htab,
> but AFAICT that's backend-local. So I don't understand what else could be
> referencing it.
Try to open a cursor that uses the function, fetch a few tuples from it;
then change the function and fetch more rows from the cursor. I suppose
the open cursor could contain a reference to the function's prodesc.
Refcounting the prodesc would let it live until the cursor's closed,
then free it.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Pierre Pelletier | 2016-02-25 15:40:13 | Re: Declarative partitioning |
Previous Message | David Steele | 2016-02-25 15:07:13 | Re: [PATCH v5] GSSAPI encryption support |