Date: Tue, 17 Mar 2026 21:01:35 +0100
From: "Peter 'PMc' Much" <pmc@citylink.dinoex.sub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tomas Vondra <tomas@vondra.me>, pgsql-hackers@lists.postgresql.org
Subject: Re: Need help debugging SIGBUS crashes
Message-ID: <abmzHxO8ywSEilI-@disp.intra.daemon.contact>
References: <ablGaVLQ3N9WsHcc@disp.intra.daemon.contact>
 <33d99d2f-4020-4615-9314-2f1a19927fa6@vondra.me>
 <392255.1773756727@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <392255.1773756727@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/abmzHxO8ywSEilI-%40disp.intra.daemon.contact>
Precedence: bulk

On Tue, Mar 17, 2026 at 10:12:07AM -0400, Tom Lane wrote:
! Tomas Vondra <tomas@vondra.me> writes:
! > On 3/17/26 13:17, Peter 'PMc' Much wrote:
! >> So I am now quite clueless on how to proceed further, and could
! >> really use some educated inspiration. I can not even say if this is
! >> a postgres issue or a FreeBSD issue (but it doesn't happen to any
! >> other program).
! 
! > I agree it's hard to deduce anything from the backtraces with the
! > interesting bits optimized out. Rebuilding the OS with -O0 might be an
! > overkill, I'd probably start by building just Postgres. That'd at least
! > give us some idea what happens there, you could inspect the memory
! > context etc.
! 
! What I'm seeing is that malloc's internal data structures are already
! corrupt during startup of an autovacuum worker.  I think the most
! likely theory is that this somehow traces to our old habit of
! launching postmaster child processes from a signal handler, something
! that violates the spirit and probably the letter of POSIX, and which
! we can clearly see was being done here.  But we got rid of that in PG
! v16, so if I were Peter my first move would be to upgrade to something
! later than 15.x.

I was considering, if there is an issue inside FreeBSD (which it
somehow looks like), then I want it hunted down as such, rather than
having it possibly covered up by using a newer version that might
do things differently.

Now, what I understand here is:
 A) I can stop searching for who is creating the SIGUSR1 signals,
     because these are created inside of PG Rel. 15.
 B) there is a potential issue in doing fork() within a sighandler,
    and then continuing to do malloc() in that new process, therefore
    this practice has been abandoned from PG Rel.16 onwards.

In that case there is indeed good reason to upgrade.

The one thing I don't get is then: as this has apparently nothing to
do with any special configurations on my site, but is a genuine issue,
then why does it happen now to me (and didn't blow up elsewhere
already some ten years ago)? 

! Why it was okay in older FreeBSD and not so much in v14, who knows?

Maybe it wasn't. Here it appeared out of thin air in February, while
the system was upgraded from 13.5 to 14.3 in July'25, and did run
without problems for these eight months.
So this is not directly or solely related to FBSD R.14, and while it
happens more likely during massive memory use, but this also is not
stingent. Neither did I find any other solid determining condition.

So yes, if there is reason to believe the annoyance might just
disappear in PG-16, then that is likely the most viable strategy.


Thanks a lot for all inspiration! :)

PMc