Re: NULL pointer dereference in syslogger with load_libraries() and -DEXEC_BACKEND at startup - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: NULL pointer dereference in syslogger with load_libraries() and -DEXEC_BACKEND at startup
Date
Msg-id 20260526.143912.747526067628586626.horikyota.ntt@gmail.com
Whole thread
In response to Re: NULL pointer dereference in syslogger with load_libraries() and -DEXEC_BACKEND at startup  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
At Tue, 26 May 2026 14:20:52 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> While thinking about an approach that could allow to keep
> 0c8e082fba8d, I was wondering whether we should have a boolean flag
> that tracks if the log file is opened or not that gets set (we should
> not care about the reset) when we are done with its creation, but I'm
> feeling that this makes the logic feeble.  We know only rely on

In write_syslogger_file, there's already a fallback path to
write_stderr() when fwrite fails. Would it make sense to treat logfile
== NULL as an error case as well?

> MyBackendType for the job which means to complicate all these checks.
> The part that makes me uneasy is that the logging facility should be
> robust by design, and simpler is always better IMO.
> 
> An exception where we don't set MyBackendType and have an exception
> for this corresponding child_type value does not really feel right to
> me either..  As a whole, I am not sure to like what has been done
> here.

Agreed.

Regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: First draft of PG 19 release notes
Next
From: Chao Li
Date:
Subject: Re: doc: Clarify ALTER CONSTRAINT enforceability wording