Re: Differential code coverage between 16 and HEAD

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

In response to

Responses

Browse pgsql-hackers by date

  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