Re: GetRelationPath() vs critical sections - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: GetRelationPath() vs critical sections
Date
Msg-id CA+hUKGLNk5ambjhaPo_BhT3x=6-ykdamVA3CZ+i06gNXH6++sQ@mail.gmail.com
Whole thread Raw
In response to GetRelationPath() vs critical sections  (Andres Freund <andres@anarazel.de>)
Responses Re: GetRelationPath() vs critical sections
List pgsql-hackers
On Wed, Feb 19, 2025 at 3:35 PM Andres Freund <andres@anarazel.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.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup
Next
From: Sami Imseih
Date:
Subject: Re: Sample rate added to pg_stat_statements