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 1ngbTt-0006Dp-Iy for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Apr 2022 00:12:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ngbTs-0001EZ-GY for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Apr 2022 00:12:32 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ngbTs-0001EQ-4y for pgsql-hackers@lists.postgresql.org; Tue, 19 Apr 2022 00:12:32 +0000 Received: from mail-pg1-x52c.google.com ([2607:f8b0:4864:20::52c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ngbTl-000098-F2 for pgsql-hackers@lists.postgresql.org; Tue, 19 Apr 2022 00:12:31 +0000 Received: by mail-pg1-x52c.google.com with SMTP id q12so21760158pgj.13 for ; Mon, 18 Apr 2022 17:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=H+hWmWd5Z10WMg37LFg16Bosodg9GgHmUZ8QdKKGNpw=; b=EXLlh1GH8EjpmV2lR5yJFpogiTkuwWwz30S2DJnsxP07JW1Wpp1Z+aAvQYRpN7dONM mUhbR8oFsucXq3qkE5rsKDrOZSuMdZm1PatSn2kFjssml0nbiW4T/I98hjBCTKhIJVpd 0tgY1shxC66MRXmh0yPaIyfku2wt2wbC0jE4g8hDhN1VazJgtNwUCaT+KgBxd2SmNDXC mzX5qfhhTxDXWiohCF7utVhDSj+ouhEQgGjIFZmY/mSR/8erFoVMPCefSEsIzfqnKrNB cbRUxdds6MmyteOzoCNytUrF66Vjr9m1g3JpppcQ7hQggh3LFExlTuPejeSrVLVbPllv dcJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=H+hWmWd5Z10WMg37LFg16Bosodg9GgHmUZ8QdKKGNpw=; b=NOV+rsuvX/l+17aKzUtFwKOUTsTmhHgNcQOrCqoS60gVRm14zmPbx9tL1yvgMA8qsd FcQijFUzdV+nkj44ls7G26rT45DU2mpVSzvcqZIEy+Ay2RjkMxTIUlY/J3BUxjhIStyb cn4suKfcYgu2U6HBqUTJM3PliF68T47EvioEwV7pEii5OJTlGKk+m/jtS89FxLN0/7t5 vgSvly9TJ15L1SnXWkyP/hyV30BW3V4qNRWaSGrtk1mjeEj1xsCebLAd6ABsipl56xRx d4QN7LIYt2X+Ye+fsywB4Yfp9DQZtbECgmRT1N5tTmU2mvAWRO6EDndrtWr1l6gSe836 HoAA== X-Gm-Message-State: AOAM530g+Vl1lenocpedjzhpFrm2mcxK5U7azqS3wkjbhtuuApY0WYxD Q8LfBLDepPsSLuKxVFLYEEU= X-Google-Smtp-Source: ABdhPJwTjvhmApi8oNI4BzDb1/XrDjsl4Y+ZQEdKbSSeAWam5grsOZDN/Qd/75oY0YuyQriEMCGOAg== X-Received: by 2002:a63:4b5d:0:b0:3aa:2a17:f7ff with SMTP id k29-20020a634b5d000000b003aa2a17f7ffmr1924838pgl.538.1650327143097; Mon, 18 Apr 2022 17:12:23 -0700 (PDT) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id g3-20020a056a000b8300b0050a833a491bsm3984080pfj.197.2022.04.18.17.12.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Apr 2022 17:12:22 -0700 (PDT) Date: Mon, 18 Apr 2022 17:12:20 -0700 From: Nathan Bossart To: Tom Lane Cc: Robert Haas , Julien Rouhaud , Andres Freund , Michael Paquier , "Bossart, Nathan" , Fujii Masao , "wangsh.fnst@fujitsu.com" , Bharath Rupireddy , Greg Sabino Mullane , "pgsql-hackers@lists.postgresql.org" Subject: Re: make MaxBackends available in _PG_init Message-ID: <20220419001220.GA2389330@nathanxps13> References: <1100207.1649864342@sss.pgh.pa.us> <1102589.1649865908@sss.pgh.pa.us> <20220413183040.GA2116671@nathanxps13> <20220414162215.GB2163833@nathanxps13> <1522578.1649954386@sss.pgh.pa.us> <20220418225244.GA2387491@nathanxps13> <2395586.1650324834@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2395586.1650324834@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Apr 18, 2022 at 07:33:54PM -0400, Tom Lane wrote: > Nathan Bossart writes: >> I noticed that requests for more LWLocks follow a similar pattern as >> regular shared memory requests, and I figured that we would want to do >> something similar for those, but I wasn't sure exactly how to proceed. I >> saw two options: 1) use shmem_request_hook for both regular requests and >> LWLock requests or 2) introduce an lwlock_request_hook. My instinct was >> that option 1 was preferable, > > Yeah, I agree, which says that maybe the hook name needs to be something > else (not that I have a good proposal). > >> but AFAICT this requires introducing a new >> external variable for inspecting whether the request is made at a valid >> time. > > Uh, why? It'd be the core code's responsibility to place the hook > call at a point where you could do both. I'm looking for a clean way to ERROR if someone attempts to call RequestAddinShmemSpace() or RequestNamedLWLockTranche() outside of the hook. Currently, we are using static variables in ipci.c and lwlock.c to silently ignore invalid requests. I could add a new 'extern bool' called 'process_shmem_requests_in_progress', but extensions could easily hack around that to allow requests in _PG_init(). Maybe I am overthinking all this and that is good enough. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com