pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL
10+ messages / 3 participants
[nested] [flat]
* BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL
@ 2025-03-14 07:58 PG Bug reporting form <noreply@postgresql.org>
2025-03-14 13:50 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
0 siblings, 1 reply; 10+ messages in thread
From: PG Bug reporting form @ 2025-03-14 07:58 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: pm91.arapov@gmail.com
The following bug has been logged on the website:
Bug reference: 18845
Logged by: Nikita
Email address: pm91.arapov@gmail.com
PostgreSQL version: 16.6
Operating system: ubuntu 20.04
Description:
guc_malloc possibly returns NULL, if no memory
I suggest the following patch fixing this issue
diff --git a/src/backend/commands/user.c b/src/backend/commands/user.c
--- a/src/backend/commands/user.c (revision
a49ac80219c6f28c3cf3973f797de637329952da)
+++ b/src/backend/commands/user.c (date 1740386879158)
@@ -2553,7 +2553,7 @@
pfree(rawstring);
list_free(elemlist);
- result = (unsigned *) guc_malloc(LOG, sizeof(unsigned));
+ result = (unsigned *) guc_malloc(FATAL, sizeof(unsigned));
*result = options;
*extra = result;
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL
2025-03-14 07:58 BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL PG Bug reporting form <noreply@postgresql.org>
@ 2025-03-14 13:50 ` Daniel Gustafsson <daniel@yesql.se>
2025-03-14 14:04 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 10+ messages in thread
From: Daniel Gustafsson @ 2025-03-14 13:50 UTC (permalink / raw)
To: pm91.arapov@gmail.com; pgsql-bugs@lists.postgresql.org
> On 14 Mar 2025, at 08:58, PG Bug reporting form <noreply@postgresql.org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 18845
> Logged by: Nikita
> Email address: pm91.arapov@gmail.com
> PostgreSQL version: 16.6
> Operating system: ubuntu 20.04
> Description:
>
> guc_malloc possibly returns NULL, if no memory
> I suggest the following patch fixing this issue
>
> diff --git a/src/backend/commands/user.c b/src/backend/commands/user.c
> --- a/src/backend/commands/user.c (revision
> a49ac80219c6f28c3cf3973f797de637329952da)
> +++ b/src/backend/commands/user.c (date 1740386879158)
> @@ -2553,7 +2553,7 @@
> pfree(rawstring);
> list_free(elemlist);
>
> - result = (unsigned *) guc_malloc(LOG, sizeof(unsigned));
> + result = (unsigned *) guc_malloc(FATAL, sizeof(unsigned));
Why would we want FATAL here? Wouldn't it be better to return false like how
other check_ functions already do?
--- a/src/backend/commands/user.c
+++ b/src/backend/commands/user.c
@@ -2566,6 +2566,8 @@ check_createrole_self_grant(char **newval, void **extra, GucSource source)
list_free(elemlist);
result = (unsigned *) guc_malloc(LOG, sizeof(unsigned));
+ if (!result)
+ return false;
*result = options;
*extra = result;
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL
2025-03-14 07:58 BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL PG Bug reporting form <noreply@postgresql.org>
2025-03-14 13:50 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
@ 2025-03-14 14:04 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-03-14 14:08 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
2025-03-14 22:10 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
0 siblings, 2 replies; 10+ messages in thread
From: Tom Lane @ 2025-03-14 14:04 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: pm91.arapov@gmail.com; pgsql-bugs@lists.postgresql.org
Daniel Gustafsson <daniel@yesql.se> writes:
> Why would we want FATAL here? Wouldn't it be better to return false like how
> other check_ functions already do?
Indeed. Also, a quick survey shows a lot of inconsistency in
guc_malloc callers --- some are lazy and just use ERROR rather
than LOG-and-return. That's probably all right for PGC_POSTMASTER
variables (since there's no chance of continuing anyway) but
perhaps it's worth improving elsewhere.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL
2025-03-14 07:58 BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL PG Bug reporting form <noreply@postgresql.org>
2025-03-14 13:50 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
2025-03-14 14:04 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Tom Lane <tgl@sss.pgh.pa.us>
@ 2025-03-14 14:08 ` Daniel Gustafsson <daniel@yesql.se>
1 sibling, 0 replies; 10+ messages in thread
From: Daniel Gustafsson @ 2025-03-14 14:08 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pm91.arapov@gmail.com; pgsql-bugs@lists.postgresql.org
> On 14 Mar 2025, at 15:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>> Why would we want FATAL here? Wouldn't it be better to return false like how
>> other check_ functions already do?
>
> Indeed. Also, a quick survey shows a lot of inconsistency in
> guc_malloc callers --- some are lazy and just use ERROR rather
> than LOG-and-return. That's probably all right for PGC_POSTMASTER
> variables (since there's no chance of continuing anyway) but
> perhaps it's worth improving elsewhere.
I'll take a look at all the other callers when preparing a patch for this to
see if there are more cases which need updating.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL
2025-03-14 07:58 BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL PG Bug reporting form <noreply@postgresql.org>
2025-03-14 13:50 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
2025-03-14 14:04 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Tom Lane <tgl@sss.pgh.pa.us>
@ 2025-03-14 22:10 ` Daniel Gustafsson <daniel@yesql.se>
2025-03-15 17:22 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 10+ messages in thread
From: Daniel Gustafsson @ 2025-03-14 22:10 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pm91.arapov@gmail.com; pgsql-bugs@lists.postgresql.org
> On 14 Mar 2025, at 15:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>> Why would we want FATAL here? Wouldn't it be better to return false like how
>> other check_ functions already do?
>
> Indeed. Also, a quick survey shows a lot of inconsistency in
> guc_malloc callers --- some are lazy and just use ERROR rather
> than LOG-and-return. That's probably all right for PGC_POSTMASTER
> variables (since there's no chance of continuing anyway) but
> perhaps it's worth improving elsewhere.
Turns out there was one more guc_malloc(LOG.. which didn't inspect the
returned allocation in check_synchronized_standby_slots. On top of that there
were a few non PGC_POSTMASTER check functions that could return false and let
the GUC machinery handle it if we want to be consistent.
The fix for check_createrole_self_grant should go down to v16 and the fix for
check_synchronized_standby_slots down to 17, the other ones aren't bugs today
so that would be a changed behaviour in backbranches.
--
Daniel Gustafsson
Attachments:
v1-0001-Fix-guc_malloc-calls-to-check-for-OOM-and-return-.patch (application/octet-stream, 4.6K) download
From 39de8e1567ff0631ab30ac010f6393a028ecdac4 Mon Sep 17 00:00:00 2001
From: Daniel Gustafsson <dgustafsson@postgresql.org>
Date: Fri, 14 Mar 2025 22:56:58 +0100
Subject: [PATCH v1] Fix guc_malloc calls to check for OOM and return false
check_createrole_self_grant and check_synchronized_standby_slots
were allocating memory on a LOG elevel without checking if the
allocation succeeded or not, which would have led to a segfault
if it didn't. The remaining calls were using the ERROR level
and relied on erroring out rather than returnin false to let
the GUC machinery handle it gracefully.
Author: Daniel Gustafsson <daniel@yesql.se>
Reported-by: Nikita <pm91.arapov@gmail.com>
Bug: #18845
Discussion: https://postgr.es/m/18845-582c6e10247377ec@postgresql.org
---
src/backend/access/transam/xlog.c | 4 +++-
src/backend/commands/user.c | 2 ++
src/backend/replication/slot.c | 2 ++
src/backend/tcop/backend_startup.c | 4 +++-
src/backend/tcop/postgres.c | 4 +++-
src/backend/utils/error/elog.c | 8 ++++++--
6 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 799fc739e18..0c4c5b9a368 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -4791,7 +4791,9 @@ check_wal_consistency_checking(char **newval, void **extra, GucSource source)
list_free(elemlist);
/* assign new value */
- *extra = guc_malloc(ERROR, (RM_MAX_ID + 1) * sizeof(bool));
+ *extra = guc_malloc(LOG, (RM_MAX_ID + 1) * sizeof(bool));
+ if (!*extra)
+ return false;
memcpy(*extra, newwalconsistency, (RM_MAX_ID + 1) * sizeof(bool));
return true;
}
diff --git a/src/backend/commands/user.c b/src/backend/commands/user.c
index 8ae510c623b..0d638e29d00 100644
--- a/src/backend/commands/user.c
+++ b/src/backend/commands/user.c
@@ -2566,6 +2566,8 @@ check_createrole_self_grant(char **newval, void **extra, GucSource source)
list_free(elemlist);
result = (unsigned *) guc_malloc(LOG, sizeof(unsigned));
+ if (!result)
+ return false;
*result = options;
*extra = result;
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index 719e531eb90..646ba2a78fa 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -2730,6 +2730,8 @@ check_synchronized_standby_slots(char **newval, void **extra, GucSource source)
/* GUC extra value must be guc_malloc'd, not palloc'd */
config = (SyncStandbySlotsConfigData *) guc_malloc(LOG, size);
+ if (!config)
+ return false;
/* Transform the data into SyncStandbySlotsConfigData */
config->nslotnames = list_length(elemlist);
diff --git a/src/backend/tcop/backend_startup.c b/src/backend/tcop/backend_startup.c
index 27c0b3c2b04..a07c59ece01 100644
--- a/src/backend/tcop/backend_startup.c
+++ b/src/backend/tcop/backend_startup.c
@@ -1078,7 +1078,9 @@ check_log_connections(char **newval, void **extra, GucSource source)
* We succeeded, so allocate `extra` and save the flags there for use by
* assign_log_connections().
*/
- *extra = guc_malloc(ERROR, sizeof(int));
+ *extra = guc_malloc(LOG, sizeof(int));
+ if (!*extra)
+ return false;
*((int *) *extra) = flags;
return true;
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index 55ab2da299b..0950a7bd1a2 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -3617,7 +3617,9 @@ check_restrict_nonsystem_relation_kind(char **newval, void **extra, GucSource so
list_free(elemlist);
/* Save the flags in *extra, for use by the assign function */
- *extra = guc_malloc(ERROR, sizeof(int));
+ *extra = guc_malloc(LOG, sizeof(int));
+ if (!*extra)
+ return false;
*((int *) *extra) = flags;
return true;
diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
index 860bbd40d42..b891dab3bf6 100644
--- a/src/backend/utils/error/elog.c
+++ b/src/backend/utils/error/elog.c
@@ -2198,7 +2198,9 @@ check_backtrace_functions(char **newval, void **extra, GucSource source)
* whitespace chars to save some memory, but it doesn't seem worth the
* trouble.
*/
- someval = guc_malloc(ERROR, newvallen + 1 + 1);
+ someval = guc_malloc(LOG, newvallen + 1 + 1);
+ if (!someval)
+ return false;
for (i = 0, j = 0; i < newvallen; i++)
{
if ((*newval)[i] == ',')
@@ -2283,7 +2285,9 @@ check_log_destination(char **newval, void **extra, GucSource source)
pfree(rawstring);
list_free(elemlist);
- myextra = (int *) guc_malloc(ERROR, sizeof(int));
+ myextra = (int *) guc_malloc(LOG, sizeof(int));
+ if (!myextra)
+ return false;
*myextra = newlogdest;
*extra = myextra;
--
2.39.3 (Apple Git-146)
=
* Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL
2025-03-14 07:58 BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL PG Bug reporting form <noreply@postgresql.org>
2025-03-14 13:50 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
2025-03-14 14:04 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Tom Lane <tgl@sss.pgh.pa.us>
2025-03-14 22:10 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
@ 2025-03-15 17:22 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-03-16 19:59 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
0 siblings, 1 reply; 10+ messages in thread
From: Tom Lane @ 2025-03-15 17:22 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: pm91.arapov@gmail.com; pgsql-bugs@lists.postgresql.org
Daniel Gustafsson <daniel@yesql.se> writes:
> On 14 Mar 2025, at 15:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Indeed. Also, a quick survey shows a lot of inconsistency in
>> guc_malloc callers --- some are lazy and just use ERROR rather
>> than LOG-and-return. That's probably all right for PGC_POSTMASTER
>> variables (since there's no chance of continuing anyway) but
>> perhaps it's worth improving elsewhere.
> Turns out there was one more guc_malloc(LOG.. which didn't inspect the
> returned allocation in check_synchronized_standby_slots. On top of that there
> were a few non PGC_POSTMASTER check functions that could return false and let
> the GUC machinery handle it if we want to be consistent.
Patch looks good as far as it goes, but I nosed around and found
a few other things:
* After sleeping on it, I think we ought to change the
guc_malloc(ERROR,...) calls in the PGC_POSTMASTER cases too.
While this won't have any functional effect, what it does do
is remove examples of bad practice that are likely to get
copied-and-pasted to somewhere where it matters. The affected
functions seem to be
check_recovery_target_lsn
check_recovery_target_timeline
check_recovery_target_xid
check_debug_io_direct
* check_application_name and check_cluster_name are using WARNING
not LOG in their guc_strdup calls. That seems to have been
decided by flipping a coin; let's sync them with everyplace else.
* init_custom_variable uses ERROR in a guc_malloc and a guc_strdup
call. These should probably be changed to FATAL, on the same grounds
that the error levels earlier in that function are FATAL: we are
partway through initializing a newly-loaded extension, so it's
unlikely that trying to continue the session is going to end well.
I agree that in the back branches it's sufficient to fix
check_createrole_self_grant and check_synchronized_standby_slots.
The rest of this is mostly about setting good examples.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL
2025-03-14 07:58 BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL PG Bug reporting form <noreply@postgresql.org>
2025-03-14 13:50 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
2025-03-14 14:04 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Tom Lane <tgl@sss.pgh.pa.us>
2025-03-14 22:10 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
2025-03-15 17:22 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Tom Lane <tgl@sss.pgh.pa.us>
@ 2025-03-16 19:59 ` Daniel Gustafsson <daniel@yesql.se>
2025-03-16 20:49 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 10+ messages in thread
From: Daniel Gustafsson @ 2025-03-16 19:59 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pm91.arapov@gmail.com; pgsql-bugs@lists.postgresql.org
> On 15 Mar 2025, at 18:22, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>> On 14 Mar 2025, at 15:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Indeed. Also, a quick survey shows a lot of inconsistency in
>>> guc_malloc callers --- some are lazy and just use ERROR rather
>>> than LOG-and-return. That's probably all right for PGC_POSTMASTER
>>> variables (since there's no chance of continuing anyway) but
>>> perhaps it's worth improving elsewhere.
>
>> Turns out there was one more guc_malloc(LOG.. which didn't inspect the
>> returned allocation in check_synchronized_standby_slots. On top of that there
>> were a few non PGC_POSTMASTER check functions that could return false and let
>> the GUC machinery handle it if we want to be consistent.
>
> Patch looks good as far as it goes, but I nosed around and found
> a few other things:
>
> * After sleeping on it, I think we ought to change the
> guc_malloc(ERROR,...) calls in the PGC_POSTMASTER cases too.
> While this won't have any functional effect, what it does do
> is remove examples of bad practice that are likely to get
> copied-and-pasted to somewhere where it matters. The affected
> functions seem to be
> check_recovery_target_lsn
> check_recovery_target_timeline
> check_recovery_target_xid
> check_debug_io_direct
>
> * check_application_name and check_cluster_name are using WARNING
> not LOG in their guc_strdup calls. That seems to have been
> decided by flipping a coin; let's sync them with everyplace else.
>
> * init_custom_variable uses ERROR in a guc_malloc and a guc_strdup
> call. These should probably be changed to FATAL, on the same grounds
> that the error levels earlier in that function are FATAL: we are
> partway through initializing a newly-loaded extension, so it's
> unlikely that trying to continue the session is going to end well.
Those are all good points, I initially didn't think we should touch the
PGC_POSTMASTER cases but you are correct that avoiding back copy pastes to
happen is a Good Thing. The attached has all these fixes added.
--
Daniel Gustafsson
Attachments:
v2-0001-Fix-guc_malloc-calls-consistency-and-OOM-checks.patch (application/octet-stream, 8.4K) download
From 1cdd367823d5d2ecb8d097e707f7408757db89d4 Mon Sep 17 00:00:00 2001
From: Daniel Gustafsson <dgustafsson@postgresql.org>
Date: Fri, 14 Mar 2025 22:56:58 +0100
Subject: [PATCH v2] Fix guc_malloc calls consistency and OOM checks
check_createrole_self_grant and check_synchronized_standby_slots
were allocating memory on a LOG elevel without checking if the
allocation succeeded or not, which would have led to a segfault
if it didn't.
On top of that, quite calls were using the ERROR level relying
on erroring out rather than returning false and leting the GUC
machinery handle it gracefully. Some other calls used WARNING
instead of LOG. While not wrong, let's make sure all check_
functions do it consistently.
init_custom_variable gets a promoted elevel to FATAL to keep
the guc_malloc error handling in line with the rest of the
error handling in that function which already call FATAL. If
we encounter an OOM here there is no graceful handling to be
had, better to error our hard.
Author: Daniel Gustafsson <daniel@yesql.se>
Reported-by: Nikita <pm91.arapov@gmail.com>
Bug: #18845
Discussion: https://postgr.es/m/18845-582c6e10247377ec@postgresql.org
---
src/backend/access/transam/xlog.c | 4 +++-
src/backend/access/transam/xlogrecovery.c | 12 +++++++++---
src/backend/commands/user.c | 2 ++
src/backend/commands/variable.c | 4 ++--
src/backend/replication/slot.c | 2 ++
src/backend/storage/file/fd.c | 8 +++++++-
src/backend/tcop/backend_startup.c | 4 +++-
src/backend/tcop/postgres.c | 4 +++-
src/backend/utils/error/elog.c | 8 ++++++--
src/backend/utils/misc/guc.c | 4 ++--
10 files changed, 39 insertions(+), 13 deletions(-)
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 799fc739e18..0c4c5b9a368 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -4791,7 +4791,9 @@ check_wal_consistency_checking(char **newval, void **extra, GucSource source)
list_free(elemlist);
/* assign new value */
- *extra = guc_malloc(ERROR, (RM_MAX_ID + 1) * sizeof(bool));
+ *extra = guc_malloc(LOG, (RM_MAX_ID + 1) * sizeof(bool));
+ if (!*extra)
+ return false;
memcpy(*extra, newwalconsistency, (RM_MAX_ID + 1) * sizeof(bool));
return true;
}
diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index 2c19013c98b..0aa3ab59085 100644
--- a/src/backend/access/transam/xlogrecovery.c
+++ b/src/backend/access/transam/xlogrecovery.c
@@ -4833,7 +4833,9 @@ check_recovery_target_lsn(char **newval, void **extra, GucSource source)
if (have_error)
return false;
- myextra = (XLogRecPtr *) guc_malloc(ERROR, sizeof(XLogRecPtr));
+ myextra = (XLogRecPtr *) guc_malloc(LOG, sizeof(XLogRecPtr));
+ if (!myextra)
+ return false;
*myextra = lsn;
*extra = myextra;
}
@@ -4997,7 +4999,9 @@ check_recovery_target_timeline(char **newval, void **extra, GucSource source)
}
}
- myextra = (RecoveryTargetTimeLineGoal *) guc_malloc(ERROR, sizeof(RecoveryTargetTimeLineGoal));
+ myextra = (RecoveryTargetTimeLineGoal *) guc_malloc(LOG, sizeof(RecoveryTargetTimeLineGoal));
+ if (!myextra)
+ return false;
*myextra = rttg;
*extra = myextra;
@@ -5033,7 +5037,9 @@ check_recovery_target_xid(char **newval, void **extra, GucSource source)
if (errno == EINVAL || errno == ERANGE)
return false;
- myextra = (TransactionId *) guc_malloc(ERROR, sizeof(TransactionId));
+ myextra = (TransactionId *) guc_malloc(LOG, sizeof(TransactionId));
+ if (!myextra)
+ return false;
*myextra = xid;
*extra = myextra;
}
diff --git a/src/backend/commands/user.c b/src/backend/commands/user.c
index 8ae510c623b..0d638e29d00 100644
--- a/src/backend/commands/user.c
+++ b/src/backend/commands/user.c
@@ -2566,6 +2566,8 @@ check_createrole_self_grant(char **newval, void **extra, GucSource source)
list_free(elemlist);
result = (unsigned *) guc_malloc(LOG, sizeof(unsigned));
+ if (!result)
+ return false;
*result = options;
*extra = result;
diff --git a/src/backend/commands/variable.c b/src/backend/commands/variable.c
index 4ad6e236d69..04cdbbd4c72 100644
--- a/src/backend/commands/variable.c
+++ b/src/backend/commands/variable.c
@@ -1087,7 +1087,7 @@ check_application_name(char **newval, void **extra, GucSource source)
if (!clean)
return false;
- ret = guc_strdup(WARNING, clean);
+ ret = guc_strdup(LOG, clean);
if (!ret)
{
pfree(clean);
@@ -1125,7 +1125,7 @@ check_cluster_name(char **newval, void **extra, GucSource source)
if (!clean)
return false;
- ret = guc_strdup(WARNING, clean);
+ ret = guc_strdup(LOG, clean);
if (!ret)
{
pfree(clean);
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index 719e531eb90..646ba2a78fa 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -2730,6 +2730,8 @@ check_synchronized_standby_slots(char **newval, void **extra, GucSource source)
/* GUC extra value must be guc_malloc'd, not palloc'd */
config = (SyncStandbySlotsConfigData *) guc_malloc(LOG, size);
+ if (!config)
+ return false;
/* Transform the data into SyncStandbySlotsConfigData */
config->nslotnames = list_length(elemlist);
diff --git a/src/backend/storage/file/fd.c b/src/backend/storage/file/fd.c
index 62f1185859f..181d43e8b17 100644
--- a/src/backend/storage/file/fd.c
+++ b/src/backend/storage/file/fd.c
@@ -4040,7 +4040,13 @@ check_debug_io_direct(char **newval, void **extra, GucSource source)
return result;
/* Save the flags in *extra, for use by assign_debug_io_direct */
- *extra = guc_malloc(ERROR, sizeof(int));
+ *extra = guc_malloc(LOG, sizeof(int));
+ if (!*extra)
+ {
+ pfree(rawstring);
+ list_free(elemlist);
+ return false;
+ }
*((int *) *extra) = flags;
return result;
diff --git a/src/backend/tcop/backend_startup.c b/src/backend/tcop/backend_startup.c
index 27c0b3c2b04..a07c59ece01 100644
--- a/src/backend/tcop/backend_startup.c
+++ b/src/backend/tcop/backend_startup.c
@@ -1078,7 +1078,9 @@ check_log_connections(char **newval, void **extra, GucSource source)
* We succeeded, so allocate `extra` and save the flags there for use by
* assign_log_connections().
*/
- *extra = guc_malloc(ERROR, sizeof(int));
+ *extra = guc_malloc(LOG, sizeof(int));
+ if (!*extra)
+ return false;
*((int *) *extra) = flags;
return true;
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index 55ab2da299b..0950a7bd1a2 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -3617,7 +3617,9 @@ check_restrict_nonsystem_relation_kind(char **newval, void **extra, GucSource so
list_free(elemlist);
/* Save the flags in *extra, for use by the assign function */
- *extra = guc_malloc(ERROR, sizeof(int));
+ *extra = guc_malloc(LOG, sizeof(int));
+ if (!*extra)
+ return false;
*((int *) *extra) = flags;
return true;
diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
index 860bbd40d42..b891dab3bf6 100644
--- a/src/backend/utils/error/elog.c
+++ b/src/backend/utils/error/elog.c
@@ -2198,7 +2198,9 @@ check_backtrace_functions(char **newval, void **extra, GucSource source)
* whitespace chars to save some memory, but it doesn't seem worth the
* trouble.
*/
- someval = guc_malloc(ERROR, newvallen + 1 + 1);
+ someval = guc_malloc(LOG, newvallen + 1 + 1);
+ if (!someval)
+ return false;
for (i = 0, j = 0; i < newvallen; i++)
{
if ((*newval)[i] == ',')
@@ -2283,7 +2285,9 @@ check_log_destination(char **newval, void **extra, GucSource source)
pfree(rawstring);
list_free(elemlist);
- myextra = (int *) guc_malloc(ERROR, sizeof(int));
+ myextra = (int *) guc_malloc(LOG, sizeof(int));
+ if (!myextra)
+ return false;
*myextra = newlogdest;
*extra = myextra;
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 12192445218..68c55d84491 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -4909,10 +4909,10 @@ init_custom_variable(const char *name,
strcmp(name, "pljava.vmoptions") == 0))
context = PGC_SUSET;
- gen = (struct config_generic *) guc_malloc(ERROR, sz);
+ gen = (struct config_generic *) guc_malloc(FATAL, sz);
memset(gen, 0, sz);
- gen->name = guc_strdup(ERROR, name);
+ gen->name = guc_strdup(FATAL, name);
gen->context = context;
gen->group = CUSTOM_OPTIONS;
gen->short_desc = short_desc;
--
2.39.3 (Apple Git-146)
=
* Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL
2025-03-14 07:58 BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL PG Bug reporting form <noreply@postgresql.org>
2025-03-14 13:50 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
2025-03-14 14:04 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Tom Lane <tgl@sss.pgh.pa.us>
2025-03-14 22:10 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
2025-03-15 17:22 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Tom Lane <tgl@sss.pgh.pa.us>
2025-03-16 19:59 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
@ 2025-03-16 20:49 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-03-17 08:26 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
0 siblings, 1 reply; 10+ messages in thread
From: Tom Lane @ 2025-03-16 20:49 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: pm91.arapov@gmail.com; pgsql-bugs@lists.postgresql.org
Daniel Gustafsson <daniel@yesql.se> writes:
> Those are all good points, I initially didn't think we should touch the
> PGC_POSTMASTER cases but you are correct that avoiding back copy pastes to
> happen is a Good Thing. The attached has all these fixes added.
I think your fix in check_debug_io_direct is wrong:
- *extra = guc_malloc(ERROR, sizeof(int));
+ *extra = guc_malloc(LOG, sizeof(int));
+ if (!*extra)
+ {
+ pfree(rawstring);
+ list_free(elemlist);
+ return false;
+ }
It looks to me like rawstring and elemlist were already freed,
so "return false" ought to be sufficient.
Also, in init_custom_variable maybe it'd be worth a comment,
along the lines of
- gen = (struct config_generic *) guc_malloc(ERROR, sz);
+ /* As above, OOM is fatal */
+ gen = (struct config_generic *) guc_malloc(FATAL, sz);
Otherwise LGTM.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL
2025-03-14 07:58 BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL PG Bug reporting form <noreply@postgresql.org>
2025-03-14 13:50 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
2025-03-14 14:04 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Tom Lane <tgl@sss.pgh.pa.us>
2025-03-14 22:10 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
2025-03-15 17:22 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Tom Lane <tgl@sss.pgh.pa.us>
2025-03-16 19:59 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
2025-03-16 20:49 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Tom Lane <tgl@sss.pgh.pa.us>
@ 2025-03-17 08:26 ` Daniel Gustafsson <daniel@yesql.se>
2025-03-27 22:49 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
0 siblings, 1 reply; 10+ messages in thread
From: Daniel Gustafsson @ 2025-03-17 08:26 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pm91.arapov@gmail.com; pgsql-bugs@lists.postgresql.org
> On 16 Mar 2025, at 21:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>> Those are all good points, I initially didn't think we should touch the
>> PGC_POSTMASTER cases but you are correct that avoiding back copy pastes to
>> happen is a Good Thing. The attached has all these fixes added.
>
> I think your fix in check_debug_io_direct is wrong:
>
> - *extra = guc_malloc(ERROR, sizeof(int));
> + *extra = guc_malloc(LOG, sizeof(int));
> + if (!*extra)
> + {
> + pfree(rawstring);
> + list_free(elemlist);
> + return false;
> + }
>
> It looks to me like rawstring and elemlist were already freed,
> so "return false" ought to be sufficient.
AFAICT it depends on the value of PG_O_DIRECT, but leaving them is the safe
option as they will be cleaned anyways.
> Also, in init_custom_variable maybe it'd be worth a comment,
> along the lines of
>
> - gen = (struct config_generic *) guc_malloc(ERROR, sz);
> + /* As above, OOM is fatal */
> + gen = (struct config_generic *) guc_malloc(FATAL, sz);
I was contemplating that but skipped it due to the really good comments in the
same function, but you are right that we might as well direct the reader.
--
Daniel Gustafsson
Attachments:
v3-0001-Fix-guc_malloc-calls-consistency-and-OOM-checks.patch (application/octet-stream, 8.4K) download
From b7bcb15c172db76f93d4f3a7a74e246b865ac6e1 Mon Sep 17 00:00:00 2001
From: Daniel Gustafsson <dgustafsson@postgresql.org>
Date: Fri, 14 Mar 2025 22:56:58 +0100
Subject: [PATCH v3] Fix guc_malloc calls consistency and OOM checks
check_createrole_self_grant and check_synchronized_standby_slots
were allocating memory on a LOG elevel without checking if the
allocation succeeded or not, which would have led to a segfault
if it didn't.
On top of that, quite calls were using the ERROR level relying
on erroring out rather than returning false and leting the GUC
machinery handle it gracefully. Some other calls used WARNING
instead of LOG. While not wrong, let's make sure all check_
functions do it consistently.
init_custom_variable gets a promoted elevel to FATAL to keep
the guc_malloc error handling in line with the rest of the
error handling in that function which already call FATAL. If
we encounter an OOM here there is no graceful handling to be
had, better to error our hard.
Author: Daniel Gustafsson <daniel@yesql.se>
Reported-by: Nikita <pm91.arapov@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Bug: #18845
Discussion: https://postgr.es/m/18845-582c6e10247377ec@postgresql.org
---
src/backend/access/transam/xlog.c | 4 +++-
src/backend/access/transam/xlogrecovery.c | 12 +++++++++---
src/backend/commands/user.c | 2 ++
src/backend/commands/variable.c | 4 ++--
src/backend/replication/slot.c | 2 ++
src/backend/storage/file/fd.c | 4 +++-
src/backend/tcop/backend_startup.c | 4 +++-
src/backend/tcop/postgres.c | 4 +++-
src/backend/utils/error/elog.c | 8 ++++++--
src/backend/utils/misc/guc.c | 5 +++--
10 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 4b6c694a3f7..fc30a52d496 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -4791,7 +4791,9 @@ check_wal_consistency_checking(char **newval, void **extra, GucSource source)
list_free(elemlist);
/* assign new value */
- *extra = guc_malloc(ERROR, (RM_MAX_ID + 1) * sizeof(bool));
+ *extra = guc_malloc(LOG, (RM_MAX_ID + 1) * sizeof(bool));
+ if (!*extra)
+ return false;
memcpy(*extra, newwalconsistency, (RM_MAX_ID + 1) * sizeof(bool));
return true;
}
diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index 2c19013c98b..0aa3ab59085 100644
--- a/src/backend/access/transam/xlogrecovery.c
+++ b/src/backend/access/transam/xlogrecovery.c
@@ -4833,7 +4833,9 @@ check_recovery_target_lsn(char **newval, void **extra, GucSource source)
if (have_error)
return false;
- myextra = (XLogRecPtr *) guc_malloc(ERROR, sizeof(XLogRecPtr));
+ myextra = (XLogRecPtr *) guc_malloc(LOG, sizeof(XLogRecPtr));
+ if (!myextra)
+ return false;
*myextra = lsn;
*extra = myextra;
}
@@ -4997,7 +4999,9 @@ check_recovery_target_timeline(char **newval, void **extra, GucSource source)
}
}
- myextra = (RecoveryTargetTimeLineGoal *) guc_malloc(ERROR, sizeof(RecoveryTargetTimeLineGoal));
+ myextra = (RecoveryTargetTimeLineGoal *) guc_malloc(LOG, sizeof(RecoveryTargetTimeLineGoal));
+ if (!myextra)
+ return false;
*myextra = rttg;
*extra = myextra;
@@ -5033,7 +5037,9 @@ check_recovery_target_xid(char **newval, void **extra, GucSource source)
if (errno == EINVAL || errno == ERANGE)
return false;
- myextra = (TransactionId *) guc_malloc(ERROR, sizeof(TransactionId));
+ myextra = (TransactionId *) guc_malloc(LOG, sizeof(TransactionId));
+ if (!myextra)
+ return false;
*myextra = xid;
*extra = myextra;
}
diff --git a/src/backend/commands/user.c b/src/backend/commands/user.c
index 8ae510c623b..0d638e29d00 100644
--- a/src/backend/commands/user.c
+++ b/src/backend/commands/user.c
@@ -2566,6 +2566,8 @@ check_createrole_self_grant(char **newval, void **extra, GucSource source)
list_free(elemlist);
result = (unsigned *) guc_malloc(LOG, sizeof(unsigned));
+ if (!result)
+ return false;
*result = options;
*extra = result;
diff --git a/src/backend/commands/variable.c b/src/backend/commands/variable.c
index 4ad6e236d69..04cdbbd4c72 100644
--- a/src/backend/commands/variable.c
+++ b/src/backend/commands/variable.c
@@ -1087,7 +1087,7 @@ check_application_name(char **newval, void **extra, GucSource source)
if (!clean)
return false;
- ret = guc_strdup(WARNING, clean);
+ ret = guc_strdup(LOG, clean);
if (!ret)
{
pfree(clean);
@@ -1125,7 +1125,7 @@ check_cluster_name(char **newval, void **extra, GucSource source)
if (!clean)
return false;
- ret = guc_strdup(WARNING, clean);
+ ret = guc_strdup(LOG, clean);
if (!ret)
{
pfree(clean);
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index 719e531eb90..646ba2a78fa 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -2730,6 +2730,8 @@ check_synchronized_standby_slots(char **newval, void **extra, GucSource source)
/* GUC extra value must be guc_malloc'd, not palloc'd */
config = (SyncStandbySlotsConfigData *) guc_malloc(LOG, size);
+ if (!config)
+ return false;
/* Transform the data into SyncStandbySlotsConfigData */
config->nslotnames = list_length(elemlist);
diff --git a/src/backend/storage/file/fd.c b/src/backend/storage/file/fd.c
index 62f1185859f..a245b70faab 100644
--- a/src/backend/storage/file/fd.c
+++ b/src/backend/storage/file/fd.c
@@ -4040,7 +4040,9 @@ check_debug_io_direct(char **newval, void **extra, GucSource source)
return result;
/* Save the flags in *extra, for use by assign_debug_io_direct */
- *extra = guc_malloc(ERROR, sizeof(int));
+ *extra = guc_malloc(LOG, sizeof(int));
+ if (!*extra)
+ return false;
*((int *) *extra) = flags;
return result;
diff --git a/src/backend/tcop/backend_startup.c b/src/backend/tcop/backend_startup.c
index 27c0b3c2b04..a07c59ece01 100644
--- a/src/backend/tcop/backend_startup.c
+++ b/src/backend/tcop/backend_startup.c
@@ -1078,7 +1078,9 @@ check_log_connections(char **newval, void **extra, GucSource source)
* We succeeded, so allocate `extra` and save the flags there for use by
* assign_log_connections().
*/
- *extra = guc_malloc(ERROR, sizeof(int));
+ *extra = guc_malloc(LOG, sizeof(int));
+ if (!*extra)
+ return false;
*((int *) *extra) = flags;
return true;
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index 55ab2da299b..0950a7bd1a2 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -3617,7 +3617,9 @@ check_restrict_nonsystem_relation_kind(char **newval, void **extra, GucSource so
list_free(elemlist);
/* Save the flags in *extra, for use by the assign function */
- *extra = guc_malloc(ERROR, sizeof(int));
+ *extra = guc_malloc(LOG, sizeof(int));
+ if (!*extra)
+ return false;
*((int *) *extra) = flags;
return true;
diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
index 860bbd40d42..b891dab3bf6 100644
--- a/src/backend/utils/error/elog.c
+++ b/src/backend/utils/error/elog.c
@@ -2198,7 +2198,9 @@ check_backtrace_functions(char **newval, void **extra, GucSource source)
* whitespace chars to save some memory, but it doesn't seem worth the
* trouble.
*/
- someval = guc_malloc(ERROR, newvallen + 1 + 1);
+ someval = guc_malloc(LOG, newvallen + 1 + 1);
+ if (!someval)
+ return false;
for (i = 0, j = 0; i < newvallen; i++)
{
if ((*newval)[i] == ',')
@@ -2283,7 +2285,9 @@ check_log_destination(char **newval, void **extra, GucSource source)
pfree(rawstring);
list_free(elemlist);
- myextra = (int *) guc_malloc(ERROR, sizeof(int));
+ myextra = (int *) guc_malloc(LOG, sizeof(int));
+ if (!myextra)
+ return false;
*myextra = newlogdest;
*extra = myextra;
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 12192445218..667df448732 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -4909,10 +4909,11 @@ init_custom_variable(const char *name,
strcmp(name, "pljava.vmoptions") == 0))
context = PGC_SUSET;
- gen = (struct config_generic *) guc_malloc(ERROR, sz);
+ /* As above, an OOM here is FATAL */
+ gen = (struct config_generic *) guc_malloc(FATAL, sz);
memset(gen, 0, sz);
- gen->name = guc_strdup(ERROR, name);
+ gen->name = guc_strdup(FATAL, name);
gen->context = context;
gen->group = CUSTOM_OPTIONS;
gen->short_desc = short_desc;
--
2.39.3 (Apple Git-146)
=
* Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL
2025-03-14 07:58 BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL PG Bug reporting form <noreply@postgresql.org>
2025-03-14 13:50 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
2025-03-14 14:04 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Tom Lane <tgl@sss.pgh.pa.us>
2025-03-14 22:10 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
2025-03-15 17:22 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Tom Lane <tgl@sss.pgh.pa.us>
2025-03-16 19:59 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
2025-03-16 20:49 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Tom Lane <tgl@sss.pgh.pa.us>
2025-03-17 08:26 ` Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL Daniel Gustafsson <daniel@yesql.se>
@ 2025-03-27 22:49 ` Daniel Gustafsson <daniel@yesql.se>
0 siblings, 0 replies; 10+ messages in thread
From: Daniel Gustafsson @ 2025-03-27 22:49 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pm91.arapov@gmail.com; pgsql-bugs@lists.postgresql.org
Took another look at this and pushed the v3 version to master with backpatches
to 16 and 17 for the access-after-alloc-failure fixes.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2025-03-27 22:49 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-03-14 07:58 BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL PG Bug reporting form <noreply@postgresql.org>
2025-03-14 13:50 ` Daniel Gustafsson <daniel@yesql.se>
2025-03-14 14:04 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-03-14 14:08 ` Daniel Gustafsson <daniel@yesql.se>
2025-03-14 22:10 ` Daniel Gustafsson <daniel@yesql.se>
2025-03-15 17:22 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-03-16 19:59 ` Daniel Gustafsson <daniel@yesql.se>
2025-03-16 20:49 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-03-17 08:26 ` Daniel Gustafsson <daniel@yesql.se>
2025-03-27 22:49 ` Daniel Gustafsson <daniel@yesql.se>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox