Re: Differential code coverage between 16 and HEAD

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