Re: Differential code coverage between 16 and HEAD
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: David Rowley <dgrowleyml@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2024-04-15T22:57:49Z
Lists: pgsql-hackers
Hi,
On 2024-04-16 10:26:57 +1200, David Rowley wrote:
> On Mon, 15 Apr 2024 at 10:33, Andres Freund <andres@anarazel.de> wrote:
> > - The new bump allocator has a fair amount of uncovered functionality:
> > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/backend/utils/mmgr/bump.c.gcov.html#L293
>
> The attached adds a test to tuplesort to exercise BumpAllocLarge()
Cool.
> > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/backend/utils/mmgr/bump.c.gcov.html#L613
>
> I don't see a way to exercise those. They're meant to be "can't
> happen" ERRORs. I could delete them and use BogusFree, BogusRealloc,
> BogusGetChunkContext, BogusGetChunkSpace instead, but the ERROR
> message would be misleading. I think it's best just to leave this.
I guess was thinking more about BumpIsEmpty() and BumpStats() then the "bogus"
cases. But BumpIsEmpty() likely is unreachable as well. BumpStats() is
reachable, but perhaps it's not worth it?
BEGIN;
DECLARE foo CURSOR FOR SELECT LEFT(a,10),b FROM (VALUES(REPEAT('a', 512 * 1024),1),(REPEAT('b', 512 * 1024),2)) v(a,b) ORDER BY v.a DESC;
FETCH 1 FROM foo;
SELECT * FROM pg_backend_memory_contexts WHERE name = 'Caller tuples';
Hm, independent of this, seems a bit odd that we don't include the memory
context type in pg_backend_memory_contexts?
Greetings,
Andres Freund
Commits
-
Push dedicated BumpBlocks to the tail of the blocks list
- 6d2fd66b9908 17.0 landed
-
Improve test coverage in bump.c
- bea97cd02ebb 17.0 landed