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 1paFK3-0004l0-OQ for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Mar 2023 12:24:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1paFK2-0001QO-Cp for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Mar 2023 12:24:38 +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 1paFK2-0001QF-0Q for pgsql-hackers@lists.postgresql.org; Thu, 09 Mar 2023 12:24:38 +0000 Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1paFJz-0005Cd-ED for pgsql-hackers@lists.postgresql.org; Thu, 09 Mar 2023 12:24:37 +0000 Received: by mail-wr1-x429.google.com with SMTP id g3so1673009wri.6 for ; Thu, 09 Mar 2023 04:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678364674; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=uWp8ZWOI8VdkhP7z0aT+HS6Mym/qtqK8CekPCZ3IWQg=; b=DFKoODm9WwQaJ/xMJXsuQ2XdTkQ+4criU9aP9f4gCZih6dGQ/JJvGhc/zD+UHqxrFe 0bjjctkiD10qwCn6OuBZxNqpbL6FJQLGu+PgeM3cOiLg+PWKlvBZ80F2vT48cvKTV5wP i3AdzeaVpG1G1lKMHk7Z5xzbjYuAxoRQ9NfXHwsuFbEO9GOVU5hncgx46NiSOBlu2Vh8 rLguBK4500C4ZK4fV1dEre5CQS5T2RVlHi/nstfRlE2AhAuAsBXAR0nki+5XTd4JWTRy 8kABmcVY+NmWNOmfSCW36VMlQFRq+8HIc3JpqJ+Lg/oRSICCUKMfOfuUgQsTIurm7UJn cAtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678364674; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uWp8ZWOI8VdkhP7z0aT+HS6Mym/qtqK8CekPCZ3IWQg=; b=VW5lXpiArZCX1Kfn6xQjvpKygiL7lZX0OY6cQVPdkK5FNv553teckFmrhNs3Fl+8rO rYot6/kIB8+xA6WdinbtGUmT802vc42bkgETxlLbdRRQwmt3Qvq3C7/H+c9OkKfMFy1g yunnMd8V3ny3AqsuSW0mZ63d9I3QpJmm8haz9wPYgWi8pM7h7Hvr5zmyYAAUZROvb8th zUqiUo6DR/sbAcefU2g04OjWqV2d4WNLO8fctEUaKHs44ry5+vK8IX1z2WOSt/b8GNPY qL4T8jWyzF3aIsWwNFJr9Chu/F+LqsYN6nIpqclBVfDya6XdVVVvwR+CPKrzP/gcEytw CQng== X-Gm-Message-State: AO0yUKV9XPAwGzlQfhFUtKsAFJZyx92JI1u25OyUm3tiltBbVx0wjduD X/idbfujqgGIIX9hmjSwP50= X-Google-Smtp-Source: AK7set88KusRIPqIy9hw13ve0uBxfx/tAuN0RGA1Sbb45anF/6K92RdxrhwgXBh9HaA2qI5W2mHxzA== X-Received: by 2002:a5d:6545:0:b0:2c7:cc8:782c with SMTP id z5-20020a5d6545000000b002c70cc8782cmr18603537wrv.1.1678364673744; Thu, 09 Mar 2023 04:24:33 -0800 (PST) Received: from [192.168.2.56] ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id m16-20020a7bca50000000b003eb5a0873e0sm2400311wml.39.2023.03.09.04.24.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Mar 2023 04:24:33 -0800 (PST) Message-ID: Date: Thu, 9 Mar 2023 13:24:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: Avoid multiple SetLatch() calls in procsignal_sigusr1_handler() Content-Language: en-US To: Bharath Rupireddy , PostgreSQL Hackers References: From: "Drouvot, Bertrand" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2/28/23 4:30 PM, Bharath Rupireddy wrote: > Hi, > > Most of the multiplexed SIGUSR1 handlers are setting latch explicitly > when the procsignal_sigusr1_handler() can do that for them at the end. Right. > These multiplexed handlers are currently being used as SIGUSR1 > handlers, not as independent handlers, so no problem if SetLatch() is > removed from them. Agree, they are only used in procsignal_sigusr1_handler(). > A few others do it right by saying /* latch will be > set by procsignal_sigusr1_handler */. Yeap, so do HandleProcSignalBarrierInterrupt() and HandleLogMemoryContextInterrupt(). > Although, calling SetLatch() in > quick succession does no harm (it just returns if the latch was > previously set), it seems unnecessary. > Agree. > I'm attaching a patch that avoids multiple SetLatch() calls. > > Thoughts? > I agree with the idea behind the patch. The thing that worry me a bit is that the changed functions are defined as external and so may produce an impact outside of core pg and I'm not sure that's worth it. Otherwise the patch LGTM. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com