From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Call rm_redo in a temporary memory context |
Date: | 2024-10-02 02:28:26 |
Message-ID: | ZvyvymRiG9irqHtr@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 01, 2024 at 03:29:19PM +0500, Kirill Reshke wrote:
> Compiler warns about `src/backend/access/transam/xlogrecovery.c:1860`,
> where we switch to maybe-uninitialized memory context. Lets assign
> this to something.
+ yourself e.g. in <varname>rm_startup</varname>. Starting with version
+ 18.0, it's called in a temporary memory context instead, and if you need
+ to retain data over calls, you need to explicitly allocate them in
+ <literal>TopMemoryContext</literal>.
Hmm. Is it a good idea to encourage that? This would be allocated in
the memory context where RmgrStartup() is called. For HEAD, it does
not matter because this is called only at the beginning of recovery in
the startup process. However, could it be a problem for out-of-core
code that wants to do a full SGMR startup and may want to rely on
something else than TopMemoryContext because the current code makes
memory context cleanup easier in the event if an error?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-10-02 02:35:19 | Re: [BUG FIX]Connection fails with whitespace after keepalives parameter value |
Previous Message | Fujii Masao | 2024-10-02 02:21:50 | Re: Inconsistency in reporting checkpointer stats |