From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Differential code coverage between 16 and HEAD |
Date: | 2024-04-15 22:57:49 |
Message-ID: | 20240415225749.xg7uq2hwuq2qmwpg@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-04-15 23:03:41 | Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~? |
Previous Message | Andres Freund | 2024-04-15 22:48:34 | Re: Stack overflow issue |