Horton

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

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

View thread
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: michael@paquier.xyz
Cc: euler@eulerto.com, pgsql-hackers@lists.postgresql.org, alvherre@kurilemu.de
Date: 2026-05-26T05:39:12Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix syslogger NULL-pointer-dereference in EXEC_BACKEND

  2. Assign "backend" type earlier during process start-up

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