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

Hi,

On Mon, 25 May 2026 at 13:52, Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Mon, May 25, 2026 at 04:45:41PM +0900, Michael Paquier wrote:
> > I did not take the cycles necessary for a bisect, but it looks like
> > this has been around for a few months at least. I have pinged
> > f3c9e341cdf1 as a safe startup point for now, so that's a 2026 issue.
>
> Well, well:
> 0c8e082fba8d36434552d3d7800abda54acafd57 is the first bad commit
> committer: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
> date: Wed, 4 Feb 2026 16:56:57 +0100
> Assign "backend" type earlier during process start-up
>
> I have also checked manually a revert of this commit, and saw that the
> problem is gone, so it does not look like I have messed up my bisect.
>

I was doing a Binary search to look for commits around those paths.

I also checked 0c8e082fba8 directly: its parent starts clean with the
same setup, while 0c8e082fba8 reports the NULL pointer passed to fwrite().

So this looks to be caused by 0c8e082fba8. After that commit, the
syslogger
child sets MyBackendType = B_LOGGER in SubPostmasterMain(), before
process_shared_preload_libraries(). A message emitted from _PG_init() then
takes the direct write_syslogger_file() path, but the syslogger FILE handles
are not reopened until later in SysLoggerMain().

So I think the bad assumption is that MyBackendType == B_LOGGER means
write_syslogger_file() is ready to use. A fix probably needs to make the
direct syslogger-file path conditional on the FILE handles being ready, and
that should cover stderr, CSV and JSON paths.

Regards,
Ayush