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