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.
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 |