Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1puJZk-0006j9-KM for pgsql-hackers@arkaria.postgresql.org; Wed, 03 May 2023 20:59:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1puJYk-0004Ab-37 for pgsql-hackers@arkaria.postgresql.org; Wed, 03 May 2023 20:58:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1puJYj-0004AS-Qd for pgsql-hackers@lists.postgresql.org; Wed, 03 May 2023 20:58:45 +0000 Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1puJYg-000Mrb-20 for pgsql-hackers@postgresql.org; Wed, 03 May 2023 20:58:44 +0000 Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-6436dfa15b3so341913b3a.1 for ; Wed, 03 May 2023 13:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683147520; x=1685739520; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=VRgz4AL2zm5Bi4IvOInMxbL+m6tQtONV84lr557392Q=; b=bgb8Ur1wvqoBhCdUaucxGzVbucA94TrIcnWlBBb/61SjUp0SdwxRLfj1QbwuB/K/TZ zZvmRH2HkmbNJC0QGLnUbUykANq5b147anZzho1Qo2rd8g3sT/0FX5yqxQ5O5IbjvB8V StLr9m57vgNsWK9m2uDaEsGF64TVfnn/UBGQKkjexxyZfRnozNDebqMGpvjAlAWMFwWu 4YjNo6iu802EjiSOmbuyG2gbs4EDpeetrNew+J77uoe0ymlRwaRO9KZt7pxM2iGbX2CM bwhPk4ee59ureqmNWUoTqATFSsQ/d6y8TOPoOuMVuSSQuwk33bFo6Q6/kZwLgxbWBlx2 lSgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683147520; x=1685739520; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VRgz4AL2zm5Bi4IvOInMxbL+m6tQtONV84lr557392Q=; b=X0x1v8LDJltJOm9D4R0yzyDIzdqm+VnarGCl1RCicBSHA/8SnQNhePAemAyYO0NOhI ZMPaht5RP7eKrDiVUJfLAwxhgdSOKhbZwONdPP0ja1/YWDnXbUOvRg8VG/X4giJ+eV+H llFuqqEFzthbOiRH0sJFq01rZqY5jPv/rbQUNDUWYcTqaevEkVp/9m48MTX6ce+xhBD9 IN8sYx7mzwCmEmCPnMcjnIs1oLhKQ/2Y8YB1cl+9W3pmC9Guf90boSKCPlXVowvcU+rZ k6uOMjdyeNiXLkW/LZvFH088+mcinOuSqqHtnp1+y4FXF0T3E9if5eBgUzJ8+T+h4Lio 7N1g== X-Gm-Message-State: AC+VfDyZg+PqC3S4bV1Mmx0rp9SfN0x7jChOEyp8bo62aIxWwhxjhRob Wpd5+fPEbZOQ2v90xX3eMLU= X-Google-Smtp-Source: ACHHUZ4nr+Zg1DV90tjUTczxgyNOMABAXX3yGjZT5VKWTPdTD+tflnGKTvMNHEtOMgfN8o86uriVCg== X-Received: by 2002:a05:6a00:b86:b0:641:4910:8837 with SMTP id g6-20020a056a000b8600b0064149108837mr20735912pfj.28.1683147520174; Wed, 03 May 2023 13:58:40 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id d17-20020aa78691000000b00640f895fde9sm14366358pfo.214.2023.05.03.13.58.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 May 2023 13:58:39 -0700 (PDT) Date: Wed, 3 May 2023 13:58:38 -0700 From: Nathan Bossart To: Tom Lane Cc: Andres Freund , Xing Guo , pgsql-hackers@postgresql.org Subject: Re: PL/Python: Fix return in the middle of PG_TRY() block. Message-ID: <20230503205838.GA2112379@nathanxps13> References: <20230112184433.GA2104952@nathanxps13> <20230113054900.b7onkvwtkrykeu3z@awork3.anarazel.de> <20230113180335.GA2160040@nathanxps13> <1864041.1673882943@sss.pgh.pa.us> <20230120010711.jpqbaelpgmuvt2vq@awork3.anarazel.de> <20230120190201.GC4106863@nathanxps13> <20230503202116.GA2110623@nathanxps13> <3012766.1683146012@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3012766.1683146012@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, May 03, 2023 at 04:33:32PM -0400, Tom Lane wrote: > Nathan Bossart writes: >> Here's a new version of the patch. Besides adding comments and a commit >> message, I made sure to decrement the reference count for pltargs in the >> PG_CATCH block (which means that pltargs likely needs to be volatile). > > Hmm, actually I think these changes should allow you to *remove* some > volatile markers. IIUC, you need volatile for variables that are declared > outside PG_TRY but modified within it. That is the case for these > pointers as the code stands, but your patch is changing them to the > non-risky case where they are assigned once before entering PG_TRY. > > (My mental model of this is that without "volatile", the compiler > may keep the variable in a register, creating the hazard that longjmp > will revert the variable's value to what it was at setjmp time thanks > to the register save/restore that those functions do. But if it hasn't > changed value since entering PG_TRY, then that doesn't matter.) Ah, I think you are right. elog.h states as follows: * Note: if a local variable of the function containing PG_TRY is modified * in the PG_TRY section and used in the PG_CATCH section, that variable * must be declared "volatile" for POSIX compliance. This is not mere * pedantry; we have seen bugs from compilers improperly optimizing code * away when such a variable was not marked. Beware that gcc's -Wclobbered * warnings are just about entirely useless for catching such oversights. With this change, pltdata isn't modified in the PG_TRY section, and the only modification of pltargs happens after all elogs. It might be worth keeping pltargs volatile in case someone decides to add an elog() in the future, but I see no need to keep it for pltdata. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com