Re: [PATCH] Allow complex data for GUC extra. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Allow complex data for GUC extra.
Date
Msg-id 3258096.1767061460@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Allow complex data for GUC extra.  (Bryan Green <dbryan.green@gmail.com>)
Responses Re: [PATCH] Allow complex data for GUC extra.
List pgsql-hackers
Bryan Green <dbryan.green@gmail.com> writes:
> On 12/29/2025 7:44 PM, Tom Lane wrote:
>> Bryan Green <dbryan.green@gmail.com> writes:
>>> One notable behavioral change: check hooks using GUC_EXTRA_IS_CONTEXT
>>> now use palloc() instead of guc_malloc().

>> Why?  It seems both inconsistent and unsafe.

> Fair enough to call me on that.  I mainly thought that if we are having
> problems allocating what is usually a few bytes then throwing an error
> would have been acceptable.

The key reason I'm allergic to this is that throwing elog(ERROR) in
the postmaster process will take down the postmaster.  So we really
do not want code that will execute during SIGHUP configuration
reloads to be doing that.  I grant that there will probably always
be edge cases where that happens, but I'm not okay with building
such a hazard into the GUC APIs.

> Based on your comment about unsafe and a
> bit deeper thinking I can see where this is probably not a welcome
> change in behavior.  I suppose we could catch the error and convert it
> to a false return.

Does

    palloc_extended(..., MCXT_ALLOC_NO_OOM)

help?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Xuneng Zhou
Date:
Subject: Re: Implement waiting for wal lsn replay: reloaded
Next
From: Lukas Fittl
Date:
Subject: Re: Refactor query normalization into core query jumbling