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 1pGVcE-0003KE-78 for pgsql-hackers@arkaria.postgresql.org; Sat, 14 Jan 2023 01:45:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pGVcC-00029H-O6 for pgsql-hackers@arkaria.postgresql.org; Sat, 14 Jan 2023 01:45:48 +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 1pGVcC-000297-Bs for pgsql-hackers@lists.postgresql.org; Sat, 14 Jan 2023 01:45:48 +0000 Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pGVc5-00031e-Ou; Sat, 14 Jan 2023 01:45:47 +0000 Received: by mail-ej1-x633.google.com with SMTP id hw16so44363997ejc.10; Fri, 13 Jan 2023 17:45:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SZC1FCDRedg6qBwrwcDl+1755wxVbhxdlyR8Qt8+1to=; b=NVGb7QJxNIFc+4JWb/NIsvehqkGeVCmVo9KVThNRzPHzf1woOxA+zPnSmHN2fBrj8z lqYaZV9exR9YhhIR0TKF6Xrxz0WRvPwnsJFDgd0Y4CMbCecI4kXa5XMHmhX7jdOFRcQ1 astvgucZhXsI692tvLSCCThjvgP5VKmNUKcV81d1CLP6eRJaD6JCdYVbRgWhUrsu2WIt sZt0I41bkTk4gRKYG9bHrilI4k0zJieLlZZkJsfIs5XpLU6jByeD0hvSEcsZEibrndqT +YLXyxjvyN+kA9CGlJVFj7vTgIrV98je3gWOe3e8852TIRjGhTmg/a/sAzkfqY4cduvN LYIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SZC1FCDRedg6qBwrwcDl+1755wxVbhxdlyR8Qt8+1to=; b=lWD4IE6IMqCxgCUKk6TE60KxBh1r1c+2btJvQWOxqLSFV+tnX+CmZquTGV29ptngsy XThK9bRXJnoHDt8migwQjvMZP2QiAPjjKBvzAMJMC0lPeYlJ8mnEHmcvBj51Mp7uFupK FYqVde7Ahn+UrEl2lI0EIpcJsmSHbY7cjyeK5rLAOCykx+9KDxB/eslP9jJGTYKZG2OA d67AbZaPITC88TxCBkj1wG22pPv5/epJailqs/+y0PdnZ68qn0DZ0Gig/GnDIsmeCjwB 9trpdJve1TJLNmZ1RVS3djobBNV1ybKUbFLXyrT0f3Oz7vxMUFRDwT3oz1vkaQBzUPvc gzdw== X-Gm-Message-State: AFqh2krIA/VSgFZNkonBSpMKNeOEUAni1MagXAB3HHfjywWVLcUAm0sH 9clIlTi5cGgmP6dWKZHb8HgFvxirmDP9+L4oBq4= X-Google-Smtp-Source: AMrXdXsKUPQU9F8Evq6zvwqh7tsrEBSfijKI/OGsLfTQU96vh8uvKuhiLX34gLefA3RpXjHFrdACcdbE10NEV67FX0A= X-Received: by 2002:a17:906:a015:b0:81b:f70c:444c with SMTP id p21-20020a170906a01500b0081bf70c444cmr8038407ejy.120.1673660740224; Fri, 13 Jan 2023 17:45:40 -0800 (PST) MIME-Version: 1.0 References: <20220925232237.p6uskba2dw6fnwj2@awork3.anarazel.de> <20221209020815.wsoixct72c6hst5l@awork3.anarazel.de> <20221229172330.jpuoljhtvivci3cd@awork3.anarazel.de> <20221229215437.s4q5lu6ijb67jugx@awork3.anarazel.de> <20230103200520.di5hjebqvi72coql@awork3.anarazel.de> <20230110020501.bujiesmhe2fuka42@awork3.anarazel.de> In-Reply-To: <20230110020501.bujiesmhe2fuka42@awork3.anarazel.de> From: Thomas Munro Date: Sat, 14 Jan 2023 14:45:06 +1300 Message-ID: Subject: Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier To: Andres Freund Cc: pgsql-hackers@postgresql.org, Robert Haas , Peter Geoghegan , Tom Lane , Fujii Masao , Bharath Rupireddy Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jan 10, 2023 at 3:05 PM Andres Freund wrote: > On 2023-01-03 12:05:20 -0800, Andres Freund wrote: > > The attached patch adds libpq-be-fe-helpers.h and uses it in libpqwalreceiver, > > dblink, postgres_fdw. > > > As I made libpq-be-fe-helpers.h handle reserving external fds, > > libpqwalreceiver now does so. I briefly looked through its users without > > seeing cases of leaking in case of errors - which would already have been bad, > > since we'd already have leaked a libpq connection/socket. > > > > > > Given the lack of field complaints and the size of the required changes, I > > don't think we should backpatch this, even though it's pretty clearly buggy > > as-is. > > Any comments on this? Otherwise I think I'll go with this approach. +1. Not totally convinced about the location but we are free to re-organise it any time, and the random CI failures are bad.