Hi, On 2024-04-16 10:26:57 +1200, David Rowley wrote: > On Mon, 15 Apr 2024 at 10:33, Andres Freund <and...@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