Re: GetRelationPath() vs critical sections

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Andy Fan <zhihuifan1213(at)163(dot)com>, pgsql-hackers(at)postgresql(dot)org, Noah Misch <noah(at)leadboat(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: Re: GetRelationPath() vs critical sections
Date: 2025-02-20 01:00:10
Message-ID: CA+hUKGLNk5ambjhaPo_BhT3x=6-ykdamVA3CZ+i06gNXH6++sQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 19, 2025 at 3:35 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> After thinking about this for an embarassingly long time, I think there's
> actually a considerably better answer for a case like this: A function that
> returns a fixed-length string by value:
>
> - Compilers can fairly easily warn about on-stack values that goes out of
> scope
>
> - Because we don't need to free the memory anymore, some code that that
> previously needed to explicitly free the memory doesn't need to anymore
> (c.f. AbortBufferIO()).
>
> - The max lenght isn't that long, so it's actually reasonably efficient,
> likely commonly cheaper than psprintf.

I like it!

> This made me realize that WaitReadBuffers() leaks a small bit of memory in the
> in zero_damaged_pages path. Hardly the end of the world, but it does show how
> annoying the current interface is.

Right. It uses relpath() for an error message, but unlike similar
examples this one is only a WARNING so it might run an unbounded
number of times before the context cleans the memory up. Not new
code, just moved around in v17.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2025-02-20 01:04:41 Re: Sample rate added to pg_stat_statements
Previous Message Andres Freund 2025-02-20 00:37:55 Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup