Thread
Commits
-
Introduce pg_dsm_registry_allocations view.
- 167ed8082f40 19 (unreleased) landed
-
like pg_shmem_allocations, but fine-grained for DSM registry ?
Florents Tselai <florents.tselai@gmail.com> — 2025-03-13T16:54:09Z
I’ve been working with the DSM registry API. I was wondering if it is possible (it doesn’t look like it) or if it has been discussed: can we expose a view like pg_shmem_allocations, but fine-grained for every named segment (i.e. created by GetNamedDSMSegment )? Currently, there is a "DSM Registry Data” entry in that view, but iiuc, it’s only about the top-level hash table the registry uses. That’s probably related to http://postgr.es/m/CAH2L28vHzRankszhqz7deXURxKncxfirnuW68zD7+hVAqaS5GQ@mail.gmail.com
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Nathan Bossart <nathandbossart@gmail.com> — 2025-03-14T14:16:50Z
On Thu, Mar 13, 2025 at 06:54:09PM +0200, Florents Tselai wrote: > I´ve been working with the DSM registry API. > I was wondering if it is possible (it doesn´t look like it) or if it has been discussed: > can we expose a view like pg_shmem_allocations, but fine-grained for every named segment (i.e. created by GetNamedDSMSegment )? > > Currently, there is a "DSM Registry Data" entry in that view, > but iiuc, it´s only about the top-level hash table the registry uses. This seems like a generally reasonable idea to me. In theory, it should be easy enough to build something that walks through the DSM registry hash table. -- nathan
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Florents Tselai <florents.tselai@gmail.com> — 2025-03-14T21:44:54Z
On Fri, Mar 14, 2025 at 4:16 PM Nathan Bossart <nathandbossart@gmail.com> wrote: > On Thu, Mar 13, 2025 at 06:54:09PM +0200, Florents Tselai wrote: > > I扉e been working with the DSM registry API. > > I was wondering if it is possible (it doesn愒 look like it) or if it has > been discussed: > > can we expose a view like pg_shmem_allocations, but fine-grained for > every named segment (i.e. created by GetNamedDSMSegment )? > > > > Currently, there is a "DSM Registry Data" entry in that view, > > but iiuc, it愀 only about the top-level hash table the registry uses. > > This seems like a generally reasonable idea to me. In theory, it should be > easy enough to build something that walks through the DSM registry hash > table. > Here's a first attempt towards a view pg_dsm_registry(name, size) that does just that So, using the test_dsm_registry module as a test bed, it would look like this. CREATE EXTENSION test_dsm_registry; SELECT set_val_in_shmem(1236); set_val_in_shmem ------------------ (1 row) -- 20 bytes = int (4 bytes) + LWLock (16bytes) SELECT * FROM pg_dsm_registry; name | size -------------------+------ test_dsm_registry | 20 (1 row) I'll create a cf entry to keep track of this -
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Florents Tselai <florents.tselai@gmail.com> — 2025-03-15T08:41:15Z
On Fri, Mar 14, 2025 at 11:44 PM Florents Tselai <florents.tselai@gmail.com> wrote: > > On Fri, Mar 14, 2025 at 4:16 PM Nathan Bossart <nathandbossart@gmail.com> > wrote: > >> On Thu, Mar 13, 2025 at 06:54:09PM +0200, Florents Tselai wrote: >> > I扉e been working with the DSM registry API. >> > I was wondering if it is possible (it doesn愒 look like it) or if it has >> been discussed: >> > can we expose a view like pg_shmem_allocations, but fine-grained for >> every named segment (i.e. created by GetNamedDSMSegment )? >> > >> > Currently, there is a "DSM Registry Data" entry in that view, >> > but iiuc, it愀 only about the top-level hash table the registry uses. >> >> This seems like a generally reasonable idea to me. In theory, it should >> be >> easy enough to build something that walks through the DSM registry hash >> table. >> > > Here's a first attempt towards a view pg_dsm_registry(name, size) that > does just that > So, using the test_dsm_registry module as a test bed, > > it would look like this. > > CREATE EXTENSION test_dsm_registry; > SELECT set_val_in_shmem(1236); > set_val_in_shmem > ------------------ > > (1 row) > > -- 20 bytes = int (4 bytes) + LWLock (16bytes) > SELECT * FROM pg_dsm_registry; > name | size > -------------------+------ > test_dsm_registry | 20 > (1 row) > > I'll create a cf entry to keep track of this > > Here's an updated v3 that fixes some white spaces v2 had—no other changes. I'm wondering though if it also makes sense to expose: - backend_pid (who created the segment) - is_pinned bool - created_at https://commitfest.postgresql.org/patch/5652/
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Sungwoo Chang <swchangdev@gmail.com> — 2025-03-19T03:46:30Z
Hi, I made a patch that adds Detach and Destroy functions for dsm registry. https://commitfest.postgresql.org/patch/5654 I was thinking, given the forementioned patch is reviewed and merged, it would be nice to add SQL command that allows manually detach or destroy the dsm registry entry. On that note, the attributes you mentioned (backend_pid, is_pinned, and created_at) will be nice information to have for users to decide which entry to detach or destroy. Especially, is_pinned will be crucial because you cannot unpin the dsm segment twice. Best regards, Sungwoo Chang 2025년 3월 15일 (토) 17:42, Florents Tselai <florents.tselai@gmail.com>님이 작성: > > > > > On Fri, Mar 14, 2025 at 11:44 PM Florents Tselai < > florents.tselai@gmail.com> wrote: > >> >> On Fri, Mar 14, 2025 at 4:16 PM Nathan Bossart <nathandbossart@gmail.com> >> wrote: >> >>> On Thu, Mar 13, 2025 at 06:54:09PM +0200, Florents Tselai wrote: >>> > I扉e been working with the DSM registry API. >>> > I was wondering if it is possible (it doesn愒 look like it) or if it >>> has been discussed: >>> > can we expose a view like pg_shmem_allocations, but fine-grained for >>> every named segment (i.e. created by GetNamedDSMSegment )? >>> > >>> > Currently, there is a "DSM Registry Data" entry in that view, >>> > but iiuc, it愀 only about the top-level hash table the registry uses. >>> >>> This seems like a generally reasonable idea to me. In theory, it should >>> be >>> easy enough to build something that walks through the DSM registry hash >>> table. >>> >> >> Here's a first attempt towards a view pg_dsm_registry(name, size) that >> does just that >> So, using the test_dsm_registry module as a test bed, >> >> it would look like this. >> >> CREATE EXTENSION test_dsm_registry; >> SELECT set_val_in_shmem(1236); >> set_val_in_shmem >> ------------------ >> >> (1 row) >> >> -- 20 bytes = int (4 bytes) + LWLock (16bytes) >> SELECT * FROM pg_dsm_registry; >> name | size >> -------------------+------ >> test_dsm_registry | 20 >> (1 row) >> >> I'll create a cf entry to keep track of this >> >> > Here's an updated v3 that fixes some white spaces v2 had—no other changes. > > I'm wondering though if it also makes sense to expose: > - backend_pid (who created the segment) > - is_pinned bool > - created_at > > https://commitfest.postgresql.org/patch/5652/ > >
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Florents Tselai <florents.tselai@gmail.com> — 2025-03-19T05:43:41Z
On Wed, Mar 19, 2025, 05:46 Sungwoo Chang <swchangdev@gmail.com> wrote: > Hi, > > I made a patch that adds Detach and Destroy functions for dsm registry. > > https://commitfest.postgresql.org/patch/5654 > Yes, I've been following that thread. I find it useful too > I was thinking, given the forementioned patch is reviewed and merged, it > would be nice to add SQL command that allows manually detach or destroy the > dsm registry entry. > Not sure I agree with this. Having some insight into what's going on in shmem it's useful I think; But exposing detach / destroy at the query level... I don't think so. Unless there's a compelling story I can't think of . > On that note, the attributes you mentioned (backend_pid, is_pinned, and > created_at) will be nice information to have for users to decide which > entry to detach or destroy. Especially, is_pinned will be crucial because > you cannot unpin the dsm segment twice. > > Best regards, > Sungwoo Chang > > > 2025년 3월 15일 (토) 17:42, Florents Tselai <florents.tselai@gmail.com>님이 작성: > >> >> >> >> >> On Fri, Mar 14, 2025 at 11:44 PM Florents Tselai < >> florents.tselai@gmail.com> wrote: >> >>> >>> On Fri, Mar 14, 2025 at 4:16 PM Nathan Bossart <nathandbossart@gmail.com> >>> wrote: >>> >>>> On Thu, Mar 13, 2025 at 06:54:09PM +0200, Florents Tselai wrote: >>>> > I扉e been working with the DSM registry API. >>>> > I was wondering if it is possible (it doesn愒 look like it) or if it >>>> has been discussed: >>>> > can we expose a view like pg_shmem_allocations, but fine-grained for >>>> every named segment (i.e. created by GetNamedDSMSegment )? >>>> > >>>> > Currently, there is a "DSM Registry Data" entry in that view, >>>> > but iiuc, it愀 only about the top-level hash table the registry uses. >>>> >>>> This seems like a generally reasonable idea to me. In theory, it >>>> should be >>>> easy enough to build something that walks through the DSM registry hash >>>> table. >>>> >>> >>> Here's a first attempt towards a view pg_dsm_registry(name, size) that >>> does just that >>> So, using the test_dsm_registry module as a test bed, >>> >>> it would look like this. >>> >>> CREATE EXTENSION test_dsm_registry; >>> SELECT set_val_in_shmem(1236); >>> set_val_in_shmem >>> ------------------ >>> >>> (1 row) >>> >>> -- 20 bytes = int (4 bytes) + LWLock (16bytes) >>> SELECT * FROM pg_dsm_registry; >>> name | size >>> -------------------+------ >>> test_dsm_registry | 20 >>> (1 row) >>> >>> I'll create a cf entry to keep track of this >>> >>> >> Here's an updated v3 that fixes some white spaces v2 had—no other changes. >> >> I'm wondering though if it also makes sense to expose: >> - backend_pid (who created the segment) >> - is_pinned bool >> - created_at >> >> https://commitfest.postgresql.org/patch/5652/ >> >>
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Sungwoo Chang <swchangdev@gmail.com> — 2025-03-20T05:12:09Z
Well, by exposing detach/destory functions at the query level, users will be able to manage dangling shmem in dsm registry if for some reason you cannot access the segment anymore. Otherwise, if a shmem segment becomes orphaned, the only thing you can do to clear the shmem resource is restarting the whole instance. It will have the same functionality as pg_backend_shutdown in a sense that you won't need to call it unless something goes wrong. Having said that, I admit it's not urgent to implement t the commands yet. Let's wait till the patches are all reviewed and merged, and we can continue the discussion from that point on. Best regards, Sungwoo Chang 2025년 3월 19일 (수) 14:43, Florents Tselai <florents.tselai@gmail.com>님이 작성: > > > On Wed, Mar 19, 2025, 05:46 Sungwoo Chang <swchangdev@gmail.com> wrote: > >> Hi, >> >> I made a patch that adds Detach and Destroy functions for dsm registry. >> >> https://commitfest.postgresql.org/patch/5654 >> > Yes, I've been following that thread. > I find it useful too > >> I was thinking, given the forementioned patch is reviewed and merged, it >> would be nice to add SQL command that allows manually detach or destroy the >> dsm registry entry. >> > > Not sure I agree with this. > Having some insight into what's going on in shmem it's useful I think; > But exposing detach / destroy at the query level... I don't think so. > Unless there's a compelling story I can't think of . > >> On that note, the attributes you mentioned (backend_pid, is_pinned, and >> created_at) will be nice information to have for users to decide which >> entry to detach or destroy. Especially, is_pinned will be crucial because >> you cannot unpin the dsm segment twice. >> >> Best regards, >> Sungwoo Chang >> >> >> 2025년 3월 15일 (토) 17:42, Florents Tselai <florents.tselai@gmail.com>님이 작성: >> >>> >>> >>> >>> >>> On Fri, Mar 14, 2025 at 11:44 PM Florents Tselai < >>> florents.tselai@gmail.com> wrote: >>> >>>> >>>> On Fri, Mar 14, 2025 at 4:16 PM Nathan Bossart < >>>> nathandbossart@gmail.com> wrote: >>>> >>>>> On Thu, Mar 13, 2025 at 06:54:09PM +0200, Florents Tselai wrote: >>>>> > I扉e been working with the DSM registry API. >>>>> > I was wondering if it is possible (it doesn愒 look like it) or if it >>>>> has been discussed: >>>>> > can we expose a view like pg_shmem_allocations, but fine-grained for >>>>> every named segment (i.e. created by GetNamedDSMSegment )? >>>>> > >>>>> > Currently, there is a "DSM Registry Data" entry in that view, >>>>> > but iiuc, it愀 only about the top-level hash table the registry uses. >>>>> >>>>> This seems like a generally reasonable idea to me. In theory, it >>>>> should be >>>>> easy enough to build something that walks through the DSM registry hash >>>>> table. >>>>> >>>> >>>> Here's a first attempt towards a view pg_dsm_registry(name, size) that >>>> does just that >>>> So, using the test_dsm_registry module as a test bed, >>>> >>>> it would look like this. >>>> >>>> CREATE EXTENSION test_dsm_registry; >>>> SELECT set_val_in_shmem(1236); >>>> set_val_in_shmem >>>> ------------------ >>>> >>>> (1 row) >>>> >>>> -- 20 bytes = int (4 bytes) + LWLock (16bytes) >>>> SELECT * FROM pg_dsm_registry; >>>> name | size >>>> -------------------+------ >>>> test_dsm_registry | 20 >>>> (1 row) >>>> >>>> I'll create a cf entry to keep track of this >>>> >>>> >>> Here's an updated v3 that fixes some white spaces v2 had—no other >>> changes. >>> >>> I'm wondering though if it also makes sense to expose: >>> - backend_pid (who created the segment) >>> - is_pinned bool >>> - created_at >>> >>> https://commitfest.postgresql.org/patch/5652/ >>> >>>
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Nathan Bossart <nathandbossart@gmail.com> — 2025-06-03T13:52:58Z
On Sat, Mar 15, 2025 at 10:41:15AM +0200, Florents Tselai wrote: > Here's an updated v3 that fixes some white spaces v2 had-no other changes. Thanks for the patch. > I'm wondering though if it also makes sense to expose: > - backend_pid (who created the segment) > - is_pinned bool > - created_at created_at might be interesting. I'm not sure the others have much use. It would be cool to surface which library/function created the segment IMHO. But for now, I'd keep the view simple and just show the contents of the DSM registry's hash table. +CREATE VIEW pg_dsm_registry AS +SELECT * FROM pg_get_dsm_registry(); I'd suggest pg_dsm_registry_allocations and pg_get_dsm_registry_allocations() to match pg_shmem_allocations. +void +iterate_dsm_registry(void (*callback)(DSMRegistryEntry *, void *), void *arg); +void +iterate_dsm_registry(void (*callback)(DSMRegistryEntry *, void *), void *arg) +{ I'm not sure what's going on here. Presumably we could just mark iterate_dsm_registry() as static. Taking a step back, I think the loop is quite overengineered. You have a function for calling dshash_seq_init/next/term, a callback function for storing the tuple, and a special struct for some SRF context. I don't see any need to abstract things to this extent. I think we should instead open-code the loop in pg_get_dsm_registry(). +/* SQL SRF showing DSM registry allocated memory */ +PG_FUNCTION_INFO_V1(pg_get_dsm_registry); There should be no need to do this. Its pg_proc.dat entry will automatically generate the required prototype. + if (rsinfo == NULL || !IsA(rsinfo, ReturnSetInfo)) + ereport(ERROR, (errmsg("pg_get_dsm_registry must be used in a SRF context"))); + + /* Set up tuple descriptor */ + tupdesc = CreateTemplateTupleDesc(2); + TupleDescInitEntry(tupdesc, (AttrNumber) 1, "name", TEXTOID, -1, 0); + TupleDescInitEntry(tupdesc, (AttrNumber) 2, "size", INT8OID, -1, 0); This SRF-related code can be simplified by using InitMaterializedSRF() and friends. Check out pg_ls_dir() in genfile.c for an example. +-- 20 bytes = int (4 bytes) + LWLock (16bytes) +SELECT * FROM pg_dsm_registry; + name | size +-------------------+------ + test_dsm_registry | 20 +(1 row) I'm a little worried about the portability of this test. I would suggest changing the query to something like SELECT size > 0 FROM pg_dsm_registry WHERE name = 'test_dsm_registry'; -- nathan -
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Florents Tselai <florents.tselai@gmail.com> — 2025-06-03T19:39:25Z
Thanks for the detailed review Nathan > On 3 Jun 2025, at 4:52 PM, Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Sat, Mar 15, 2025 at 10:41:15AM +0200, Florents Tselai wrote: >> Here's an updated v3 that fixes some white spaces v2 had-no other changes. > > Thanks for the patch. > >> I'm wondering though if it also makes sense to expose: >> - backend_pid (who created the segment) >> - is_pinned bool >> - created_at > > created_at might be interesting. I'm not sure the others have much use. > It would be cool to surface which library/function created the segment > IMHO. But for now, I'd keep the view simple and just show the contents of > the DSM registry's hash table. > > +CREATE VIEW pg_dsm_registry AS > +SELECT * FROM pg_get_dsm_registry(); > > I'd suggest pg_dsm_registry_allocations and > pg_get_dsm_registry_allocations() to match pg_shmem_allocations. > > +void > +iterate_dsm_registry(void (*callback)(DSMRegistryEntry *, void *), void *arg); > +void > +iterate_dsm_registry(void (*callback)(DSMRegistryEntry *, void *), void *arg) > +{ > > I'm not sure what's going on here. Presumably we could just mark > iterate_dsm_registry() as static. > > Taking a step back, I think the loop is quite overengineered. You have a > function for calling dshash_seq_init/next/term, a callback function for > storing the tuple, and a special struct for some SRF context. I don't see > any need to abstract things to this extent. I think we should instead > open-code the loop in pg_get_dsm_registry(). > > +/* SQL SRF showing DSM registry allocated memory */ > +PG_FUNCTION_INFO_V1(pg_get_dsm_registry); > > There should be no need to do this. Its pg_proc.dat entry will > automatically generate the required prototype. > > + if (rsinfo == NULL || !IsA(rsinfo, ReturnSetInfo)) > + ereport(ERROR, (errmsg("pg_get_dsm_registry must be used in a SRF context"))); > + > + /* Set up tuple descriptor */ > + tupdesc = CreateTemplateTupleDesc(2); > + TupleDescInitEntry(tupdesc, (AttrNumber) 1, "name", TEXTOID, -1, 0); > + TupleDescInitEntry(tupdesc, (AttrNumber) 2, "size", INT8OID, -1, 0); > > This SRF-related code can be simplified by using InitMaterializedSRF() and > friends. Check out pg_ls_dir() in genfile.c for an example. > > +-- 20 bytes = int (4 bytes) + LWLock (16bytes) > +SELECT * FROM pg_dsm_registry; > + name | size > +-------------------+------ > + test_dsm_registry | 20 > +(1 row) > > I'm a little worried about the portability of this test. I would suggest > changing the query to something like > > SELECT size > 0 FROM pg_dsm_registry WHERE name = 'test_dsm_registry'; > > -- > nathan Attaching a v4 which resolves these and also adds a doc entry. -
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Nathan Bossart <nathandbossart@gmail.com> — 2025-06-03T19:53:15Z
On Tue, Jun 03, 2025 at 10:39:25PM +0300, Florents Tselai wrote: > Thanks for the detailed review Nathan Thanks for the updated patch! + if (rsinfo == NULL || !IsA(rsinfo, ReturnSetInfo)) + ereport(ERROR, (errmsg("pg_get_dsm_registry_allocations must be used in a SRF context"))); InitMaterializedSRF() takes care of this for you. +typedef struct +{ + Tuplestorestate *tupstore; + TupleDesc tupdesc; +} DSMRegistrySRFContext; This appears to be unused. +#include "fmgr.h" +#include "funcapi.h" +#include "miscadmin.h" +#include "utils/builtins.h" Do we need fmgr.h and miscadmin.h? Also, please alphabetize these into the existing list of #includes. + values[1] = Int64GetDatum(entry->size); I think there's a sign mismatch problem here, but it seems implausible in practice. pg_get_shmem_allocations() does the same thing. + <sect1 id="view-pg-dsm-registry-allocations"> + <title><structname>pg_dsm_registry_allocations</structname></title> We need to add an entry into the System Views table in the Overview page, too. -- nathan -
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Florents Tselai <florents.tselai@gmail.com> — 2025-06-03T20:07:31Z
> On 3 Jun 2025, at 10:53 PM, Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Tue, Jun 03, 2025 at 10:39:25PM +0300, Florents Tselai wrote: >> Thanks for the detailed review Nathan > > Thanks for the updated patch! > > + if (rsinfo == NULL || !IsA(rsinfo, ReturnSetInfo)) > + ereport(ERROR, (errmsg("pg_get_dsm_registry_allocations must be used in a SRF context"))); > > InitMaterializedSRF() takes care of this for you. > > +typedef struct > +{ > + Tuplestorestate *tupstore; > + TupleDesc tupdesc; > +} DSMRegistrySRFContext; > > This appears to be unused. > > +#include "fmgr.h" > +#include "funcapi.h" > +#include "miscadmin.h" > +#include "utils/builtins.h" > > Do we need fmgr.h and miscadmin.h? Also, please alphabetize these into the > existing list of #includes. > > + values[1] = Int64GetDatum(entry->size); > > I think there's a sign mismatch problem here, but it seems implausible in > practice. pg_get_shmem_allocations() does the same thing. > > + <sect1 id="view-pg-dsm-registry-allocations"> > + <title><structname>pg_dsm_registry_allocations</structname></title> > > We need to add an entry into the System Views table in the Overview page, > too. > > -- > nathan -
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Nathan Bossart <nathandbossart@gmail.com> — 2025-06-03T20:23:42Z
This latest patch set looks pretty good to me. -- nathan
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Florents Tselai <florents.tselai@gmail.com> — 2025-06-04T08:17:42Z
On Tue, Jun 3, 2025 at 11:23 PM Nathan Bossart <nathandbossart@gmail.com> wrote: > This latest patch set looks pretty good to me. > Thanks; let's wait a bit to see if there're any objections. If not, I've taken note of > created_at might be interesting. For a separate patch .
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Nathan Bossart <nathandbossart@gmail.com> — 2025-06-04T16:19:28Z
On Wed, Jun 04, 2025 at 11:17:42AM +0300, Florents Tselai wrote: > Thanks; let's wait a bit to see if there're any objections. Would you mind combining the patches into just one patch? That's how I reviewed it, and that's how it would be committed. -- nathan
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Florents Tselai <florents.tselai@gmail.com> — 2025-06-04T18:03:03Z
> On 4 Jun 2025, at 7:19 PM, Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Wed, Jun 04, 2025 at 11:17:42AM +0300, Florents Tselai wrote: >> Thanks; let's wait a bit to see if there're any objections. > > Would you mind combining the patches into just one patch? That's how I > reviewed it, and that's how it would be committed. > This works ?
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Nathan Bossart <nathandbossart@gmail.com> — 2025-06-04T21:42:01Z
On Wed, Jun 04, 2025 at 09:03:03PM +0300, Florents Tselai wrote: > On 4 Jun 2025, at 7:19 PM, Nathan Bossart <nathandbossart@gmail.com> wrote: >> Would you mind combining the patches into just one patch? That's how I >> reviewed it, and that's how it would be committed. > > This works ? Yes, thanks. -- nathan
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Nathan Bossart <nathandbossart@gmail.com> — 2025-06-24T20:33:31Z
I think this will need some rework to deal with the addition of GetNamedDSA() and GetNamedDSHash() [0]. We probably want to add a "type" column to show whether the entry is for a DSM, DSA, or dshash table. And for DSAs and dshash tables, we probably want to use dsa_get_total_size() for the "size" column. [0] https://postgr.es/m/flat/aEC8HGy2tRQjZg_8@nathan -- nathan
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Florents Tselai <florents.tselai@gmail.com> — 2025-07-08T11:17:54Z
> On 25 Jun 2025, at 4:33 AM, Nathan Bossart <nathandbossart@gmail.com> wrote: > > for DSAs and dshash tables, we probably want to use dsa_get_total_size() > for the "size" column. > The thing is that dsa_get_total_size expects an already attached dsa. I can't see how it's possible to get the actual size for the dsa and dsh case, without attaching and then using, dsa_get_total_size on the attached dsa. And I don't think we wanna do that. Instead maybe we can just report NULL for the dsa and dsh cases? Here’s a v5 that does it like that
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Nathan Bossart <nathandbossart@gmail.com> — 2025-07-08T15:21:22Z
On Tue, Jul 08, 2025 at 07:17:54PM +0800, Florents Tselai wrote: > I can't see how it's possible to get the actual size for the dsa and dsh case, > without attaching and then using, dsa_get_total_size on the attached dsa. > And I don't think we wanna do that. > > Instead maybe we can just report NULL for the dsa and dsh cases? Yeah, I'm not sure what else we can do about that without a bunch of refactoring work on the DSA/dshash side, and it's probably not worth the effort, anyway. -- nathan
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Florents Tselai <florents.tselai@gmail.com> — 2025-07-08T16:13:04Z
> On 8 Jul 2025, at 11:21 PM, Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Tue, Jul 08, 2025 at 07:17:54PM +0800, Florents Tselai wrote: >> I can't see how it's possible to get the actual size for the dsa and dsh case, >> without attaching and then using, dsa_get_total_size on the attached dsa. >> And I don't think we wanna do that. >> >> Instead maybe we can just report NULL for the dsa and dsh cases? > > Yeah, I'm not sure what else we can do about that without a bunch of > refactoring work on the DSA/dshash side, and it's probably not worth the > effort, anyway. I agree. In that case I think v5 should be enough.
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Nathan Bossart <nathandbossart@gmail.com> — 2025-07-08T20:11:52Z
Here is what I have staged for commit, which I'm planning to do tomorrow. -- nathan
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Florents Tselai <florents.tselai@gmail.com> — 2025-07-09T11:27:22Z
On Tue, Jul 8, 2025 at 11:11 PM Nathan Bossart <nathandbossart@gmail.com> wrote: > Here is what I have staged for commit, which I'm planning to do tomorrow. > > I agree with your improvements as well; thanks.
-
Re: like pg_shmem_allocations, but fine-grained for DSM registry ?
Nathan Bossart <nathandbossart@gmail.com> — 2025-07-09T14:18:45Z
Committed. -- nathan