Re: Call rm_redo in a temporary memory context

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

In response to

Browse pgsql-hackers by date

  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