Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w74aG-004vxc-0P for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Mar 2026 04:50:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w74aE-001H3f-14 for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Mar 2026 04:50:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w74aD-001H3W-2v for pgsql-hackers@lists.postgresql.org; Mon, 30 Mar 2026 04:50:38 +0000 Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w74aC-00000001kZS-2NiG for pgsql-hackers@postgresql.org; Mon, 30 Mar 2026 04:50:37 +0000 Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-43cfac48bc7so416741f8f.0 for ; Sun, 29 Mar 2026 21:50:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774846235; cv=none; d=google.com; s=arc-20240605; b=FNxeJT38aoaps5FKumgY4wj1R3H55rjtsAfAKxcrenXKZ+fhsh5KPEoS495huaPSd4 2KC9WP99ghO4qpmovyP+2BwyoJ3svBZHysWaeXGOIAPFvSTFVPot4Y0te+CfS2cfGtwN fCutPifhA77S4N8izFnftFrLtoRd2qjGZgZL/f2VO4qmIXzgOMwY5O9qHhpVvkjMecpM DVjLXchHtZUZKh7dsG0vns3T9OmCKMW8c2D9RNqs1wh7ObX867AEaxPttPf4OqFDaZ8D zBOED1PaRiCdPRaatQiLcKl6BlHYOnISv4sdR3/YJYNelhAkUSjVpvHmoh/Z3CPqqHx9 /tQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=p26VTePNWFN6C5+LjVfZOb4AJyLnOD7N28lvfxPbs2I=; fh=zw8t+Ckqik0yA4vnHOBtWMYclb4rJuoO1YbfM2b/K0s=; b=gz4Cn0YbCjD2temwt+7/Pmo6J4NjUlVgAjft+oOPCVFgoZ+mnhOo8UpYPNXt3sRFNe 1AWBY9xfNDCSlPf6T1bh9kBdFFUmyjODBqs/NyQNTLT4jyfuONUgoOO6pn0oi0nFWpmU SFQ7vLtrmDbBPp3GUJjhbB41+38vvdij5TXz81owP3fkRjtyugUElXiBAIFaQ9faxAja +NJzOkXednSNk0NZZUlOyEwgGg++iElm7erGL9u7/v/PoQwhrt1AtZ12J2lK+u5+vnVC vuR54NCXO+LuhcaBpbJu8LiWVQP5+Zqd/4liBsvbRAP7jhcasZMoDU/ITCgz0EDa6YI4 dpMw==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774846235; x=1775451035; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=p26VTePNWFN6C5+LjVfZOb4AJyLnOD7N28lvfxPbs2I=; b=goPTTF0cUoscC541VECYsjtEwV5T2bt7NRLAqmUEr2nP5rzk4x7d/G6S37I3sYzKtC 7viGaI0ykeNn/56yt2epPEps/EFEJqNu682j0s687c+jnC+q9zfJeMSdSMNA7DRxW81O qaBTMpgnbE35KdAlhCFt1YU9IUAVrVnZIMZTBa+necFrtW/OePoQdz0x6Hyc/kpFtNOv e00TFQl4fELs5+HVkNZ6gUX0BqLBmLEa43Bu/DZROW8Dh/+sQuPOYqnH0bITpN1Bw/8m X2eAQm1ByCmmMBwDulNgKfVlxRT2GOIQVuMg4z+1CMq656tV/BOZAvxz7YEFPhDfA4Sp R/Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774846235; x=1775451035; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=p26VTePNWFN6C5+LjVfZOb4AJyLnOD7N28lvfxPbs2I=; b=dSI4hUS4Bl2hYKZk3Ox+2g2Yy80l69ir9c2QYCJjjX8nexE+gp0/kOAkfYdPwKr17w ZEijSHVdNRHj5v1/G9oq+jPkTp1UDe9E5mEDfpoEsl4K4JGOqMorw6/Y20SOCljThS57 VJYHSH0w1ECLqxyL/estMUtEsuHum6zPly6Bz1P1khfy1BXazO5nIe5SSNtpYo6JYm3N jXYo0UtXBurDzoA3Dxfl24FODHzgDsrsq77bNwBmPp7zZOgwhtIdXmdf1N/fRNceCyaa LIzrYG2Yid0IftYPdLvEf17hbYC9UAbgOqC2KQGwFw8VHCv2pmur3naILBcAgVUqoLHx 6peg== X-Forwarded-Encrypted: i=1; AJvYcCUSqEdsEhV7smGB0c5JUWHhVku2EKQcN160asvGMBDRi4bJGwKFJ38ko1AIkE+PwE0Vi3fS9goG1bRBt4a8@postgresql.org X-Gm-Message-State: AOJu0Yx8doKUi2liH464udq6a311lxvqxaK2l8gGfazYX52eVa9gT+M5 I3ibkgrFVs0Mh9zBXbEZSclCATkQsunBuZiXqmTZRyHSgel4DnfwqYKfbeJyEP201MEcydBcYeZ iupueFxJE4ovKytvE7TJ1fBUbWYzi6eBPGXGq X-Gm-Gg: ATEYQzzhKCURKfJrLr5X7daD6dueO68YbYxO9WDrDJ8jk/yGBUQE2gSXK/UYpOk2O1g v0ezl4c/OUQJJ/Lifi2spjfLnZjpzZulQKNKui2Waj45RhBGglSq0Rfao0yMUN3yoby2oLR+lkF nwSd5QBoaaTEmhMkUqWb/K7EmQMmcmx4GBt5r0iaQs0XsXxmKJBaAv2jz94MmZaj+wI23Ccu5y/ lpxbBpBRVEEX3wEGWGGAWsWaIn/LL3PcAbNuzz1Qld9ZKnueGcjRSCLfx5f5eXYfANvgW6G4L1m 8eBzeTpIi6flkNvmNkpZZIgJkOUSufP7vp2k4emABznaAuW9qQ== X-Received: by 2002:a05:6000:2313:b0:43c:fa77:f71a with SMTP id ffacd0b85a97d-43cfa77f7d1mr6356568f8f.15.1774846234844; Sun, 29 Mar 2026 21:50:34 -0700 (PDT) MIME-Version: 1.0 References: <62b8dc23-8f6a-4cac-91ff-f74bb5bc159a@iki.fi> <8a6799be-bd42-49fb-8914-856c97bb1977@iki.fi> <113724ab-0028-493f-9605-6e8570f0939f@iki.fi> In-Reply-To: From: Ashutosh Bapat Date: Mon, 30 Mar 2026 10:20:22 +0530 X-Gm-Features: AQROBzCeAgcy432sRyu4w0hnLPgb9KCB0_WbWLMe_EzvU8A5jGJPmlsDw6Ur7Us Message-ID: Subject: Re: Better shared data structure management and resizable shared data structures To: Heikki Linnakangas Cc: Robert Haas , Andres Freund , pgsql-hackers , chaturvedipalak1911@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Mar 28, 2026 at 4:47=E2=80=AFAM Heikki Linnakangas wrote: > > Thanks, will incorporate your comments in next version. Replying to just > a few of them here: > > On 27/03/2026 09:01, Ashutosh Bapat wrote: > > /* Restore basic shared memory pointers */ > > if (UsedShmemSegAddr !=3D NULL) > > + { > > InitShmemAllocator(UsedShmemSegAddr); > > + ShmemCallRequestCallbacks(); > > > > It's not clear how we keep the list of registered callbacks across the > > backends and also after restart in-sync. How do we make sure that the > > callbacks registered at this time are the same callbacks registered > > before creating the shared memory? How do we make sure that the > > callbacks registered after the startup are also registered after > > restart? > > On Unix systems, the registered callbacks are inherited by fork(), and > also survive over crash restart. With EXEC_BACKEND, the assumption is > that calling a library's _PG_init() function will register the same > callbacks every time. We make the same assumption today with the > shmem_startup hook. > RegisterShmemCallbacks() may be called after the startup, and it will add new areas to the shared memory. How are those registries synced across the backends? From your answer below, those registries are not synced across backends. They will be wiped out by the restart and won't be registered again. Is that right? I think we need to document this fact and also the need to call RegisterShmemCallbacks() from all the backends where the new areas are required after the startup. Sorry, my question was not complete. > > +void > > +RegisterShmemCallbacks(const ShmemCallbacks *callbacks) > > ... snip ... > > + foreach(lc, requested_shmem_areas) > > > > Doesn't this list contain all the areas, not just registered in this > > instance of the call. Does that mean that we need to have all the > > attach functions idempotent? Why can't we deal with the newly > > registered areas only? > > registered_shmem_areas is supposed to be empty when the function is > entered. There's an assertion for that too before the foreach(). > > However, it's missing this, after processing the list: > > list_free_deep(requested_shmem_areas); > requested_shmem_areas =3D NIL; > > Because of that, this will fail if you load multiple extensions that > call RegisterShmemCallbacks() in the same session. Will fix that. -- Best Wishes, Ashutosh Bapat