Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 58A289FC2A8 for ; Fri, 11 May 2007 10:40:16 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 81775-09 for ; Fri, 11 May 2007 10:40:04 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from gmp-ea-fw-1.sun.com (gmp-ea-fw-1.sun.com [192.18.1.36]) by postgresql.org (Postfix) with ESMTP id 03DBB9FC275 for ; Fri, 11 May 2007 10:40:02 -0300 (ADT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4BDe0ng011178 for ; Fri, 11 May 2007 13:40:01 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHV00001PUWI800@d1-emea-09.sun.com> (original mail from Zdenek.Kotala@Sun.COM) for pgsql-hackers@postgresql.org; Fri, 11 May 2007 14:40:00 +0100 (BST) Received: from [129.150.120.147] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHV005J4PYEWC34@d1-emea-09.sun.com>; Fri, 11 May 2007 14:39:51 +0100 (BST) Date: Fri, 11 May 2007 15:39:50 +0200 From: Zdenek Kotala Subject: Re: race condition in pgplsql call handler? In-reply-to: <17475.1178888659@sss.pgh.pa.us> To: Tom Lane Cc: PostgreSQL-development Message-id: <46447226.1020401@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <464427E9.6030101@sun.com> <17475.1178888659@sss.pgh.pa.us> User-Agent: Thunderbird 1.5.0.8 (X11/20061204) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200705/466 X-Sequence-Number: 103068 Tom Lane wrote: > Zdenek Kotala writes: >> I'm looking into PG/PLSql code and following code in >> plpgsql_call_handler looks strange: > >> /* Find or compile the function */ >> func = plpgsql_compile(fcinfo, false); > >> /* Mark the function as busy, so it can't be deleted from under >> us */ >> func->use_count++; > > >> I don't have deep knowledge about this part of code. But what happen if >> in parallel execution "func" will be deleted between these two lines? > > This is not a race condition because the backend is single-threaded. I see. Each backend has own function cache and use_count is for handle recursion usage. Are my assumption correct? thanks Zdenek