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 1q02MB-0003jC-9m for pgsql-hackers@arkaria.postgresql.org; Fri, 19 May 2023 15:49:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q02MA-0001wF-78 for pgsql-hackers@arkaria.postgresql.org; Fri, 19 May 2023 15:49:26 +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 1q02M9-0001w6-TO for pgsql-hackers@lists.postgresql.org; Fri, 19 May 2023 15:49:25 +0000 Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1q02M7-000hIn-7o for pgsql-hackers@lists.postgresql.org; Fri, 19 May 2023 15:49:24 +0000 Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-2536b4b3398so1596634a91.3 for ; Fri, 19 May 2023 08:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timescale.com; s=google; t=1684511362; x=1687103362; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=HG0woiTnXeYn/uzHpkJ0Mf7qpp0KlA2SbhNS1AsP5Eg=; b=jeVauXhb0sgQZe3RXyZ/EB3ZvYCe4RuvzQTNZ2aEiJK8HL+y4xjwtyYLblokOC5HMp QyvO8CskvDA4IQS1dSYMAQLMKhUo0BUZ3qzlvr6HSVZ3HmMaJYcAXfmJj8jtEz/hT251 H78KgSQG891vTwmtDxdPmWBjpwhvOIcsCppQlcPoXYcToWXzU5X4r8lMf4NsR5K7QhhQ 51rr1jISfoqu7aJyxWWqPZ+Mmb1bdCxTXoyy4LdOiMS9qekXtEfO5NkCqCmJXObnw+QN WGisFTG1WqQZKPMTvnJPeyQHR4P4/v9L9JggQzQ/N1Gp8eubt4AKsactBAG2vAYGk/3G eWWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684511362; x=1687103362; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=HG0woiTnXeYn/uzHpkJ0Mf7qpp0KlA2SbhNS1AsP5Eg=; b=fJs/49OPNXe7VbdkxpQrOqALYa4UE65x6WZwLRa7ys64VmZNc0HSoq+H+E3T1HTmiw 8Z7VG1y8CF9yZK0yuQR6J7Kfy6oGe916GL5tHHArooORAbMzu4yuqWp1YFdrRlsXX3Rj jU3gjptJYWTI0wf0J2etgGxDs5oWFpmNQVgO10mN4cjEtI6jXSLAO2ijh/FmcaJmmbNv 1MfYgq627HDzxXdTozoIL94xDIagnf794JHOVGiPXa05k9a1IXSm0x4Wh/P/IOFKX8Zj Ja/LBqFxCaT4kD6s0S913TvHWRDbLfEEWHsc/RgTZRgOLSgVT68Qxn5351Hp17cbO5P2 0Xlw== X-Gm-Message-State: AC+VfDxPq88s5+hny5+9aQNdxXkxleg6InoDt2hM5fpNDZnpJaCjWWHl 2OArTvXfIOAvwOOh2MWqJY9c5t7h875W8UXNK62PEvqbWZ1iz/DO8QEpIA== X-Google-Smtp-Source: ACHHUZ57XKqHJcKdx7vEFbtbP2pfAcTB4BhTyqvx8S5cxpgaEXn3bJ1YmCGN8587MTSffHWhkrEBwrh4Uh8/4yC24cQ= X-Received: by 2002:a17:90a:f991:b0:250:7ece:4461 with SMTP id cq17-20020a17090af99100b002507ece4461mr2516066pjb.34.1684511362205; Fri, 19 May 2023 08:49:22 -0700 (PDT) MIME-Version: 1.0 From: Aleksander Alekseev Date: Fri, 19 May 2023 18:49:11 +0300 Message-ID: Subject: "38.10.10. Shared Memory and LWLocks" may require a clarification To: PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, While re-reading 38.10.10. Shared Memory and LWLocks [1] and the corresponding code in pg_stat_statements.c I noticed that there are several things that can puzzle the reader. The documentation and the example suggest that LWLock* should be stored within a structure in shared memory: ``` typedef struct pgssSharedState { LWLock *lock; /* ... etc ... */ } pgssSharedState; ``` ... and initialized like this: ``` LWLockAcquire(AddinShmemInitLock, LW_EXCLUSIVE); pgss = ShmemInitStruct("pg_stat_statements", sizeof(pgssSharedState), &found); if (!found) { pgss->lock = &(GetNamedLWLockTranche("pg_stat_statements"))->lock; /* ... */ } /* ... */ LWLockRelease(AddinShmemInitLock); ``` It is not clear why placing LWLock* in a local process memory would be a bug. On top of that the documentation says: """ To avoid possible race-conditions, each backend should use the LWLock AddinShmemInitLock when connecting to and initializing its allocation of shared memory """ However it's not clear when a race-condition may happen. The rest of the text gives an overall impression that the shmem_startup_hook will be called by postmaster once (unless an extension places several hooks in series). Thus there is no real need to ackquire AddinShmemInitLock and it should be safe to store LWLock* in local process memory. This memory will be inherited from postmaster by child processes and the overall memory usage is going to be the same due to copy-on-write. Perhaps we should clarify this. Thoughts? [1]: https://www.postgresql.org/docs/15/xfunc-c.html#XFUNC-SHARED-ADDIN -- Best regards, Aleksander Alekseev