Hi, On 2024-04-16 13:50:14 +1200, David Rowley wrote: > I think primarily it's good to exercise that code just to make sure it > does not crash. Looking at the output of the above on my machine:
Agreed. > name | ident | parent | level | total_bytes | > total_nblocks | free_bytes | free_chunks | used_bytes > ---------------+-------+----------------+-------+-------------+---------------+------------+-------------+------------ > Caller tuples | | TupleSort sort | 6 | 1056848 | > 3 | 8040 | 0 | 1048808 > (1 row) > > I'd say: > > Name: stable > ident: stable > parent: stable > level: could change from a refactor of code > total_bytes: could be different on other platforms or dependent on > MEMORY_CONTEXT_CHECKING > total_nblocks: stable enough > free_bytes: could be different on other platforms or dependent on > MEMORY_CONTEXT_CHECKING > free_chunks: always 0 > used_bytes: could be different on other platforms or dependent on > MEMORY_CONTEXT_CHECKING I think total_nblocks might also not be entirely stable? How about just checking if total_bytes, total_nblocks, free_bytes and used_bytes are bigger than 0? > I cut the 2nd row down to just 512 bytes as I didn't see the need to > add two large datums. Agreed, I just quickly hacked the statement up based on your earlier one. Looks good to me, either testing the other columns with > 0 or as you have it. > > Hm, independent of this, seems a bit odd that we don't include the memory > > context type in pg_backend_memory_contexts? > > That seems like useful information to include. It sure would be > useful to have in there to verify that I'm testing BumpStats(). I've > written a patch [2]. Nice! Greetings, Andres Freund