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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
