From: Tom Lane <tgl@sss.pgh.pa.us>
To: wobbet@wobbet.com, Robert Sanford <wobbet@gmail.com>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18076: Consistently receiving Signal 7 and Signal 11 errors
In-reply-to: 
 <CABa+nRtZoekMo5yFcF_CpcaMShtaBjexr24-xcnFOBS2b4bnAA@mail.gmail.com>
References: <18076-acf41deb61815178@postgresql.org>
 <CABa+nRtZoekMo5yFcF_CpcaMShtaBjexr24-xcnFOBS2b4bnAA@mail.gmail.com>
Comments: In-reply-to Robert Sanford <wobbet@gmail.com>
	message dated "Tue, 29 Aug 2023 16:37:13 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <169800.1693401951.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 30 Aug 2023 09:25:51 -0400
Message-ID: <169801.1693401951@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/169801.1693401951%40sss.pgh.pa.us>
Precedence: bulk

Robert Sanford <wobbet@gmail.com> writes:
> Using the Azure VM monitor I see that available memory has not ever gone
> below 50% so work_mem may not be the issue.

There was never any reason to think that.

>> 2023-08-29 01:50:57.225 UTC [432307] LOG:  server process (PID 433701) =
was
>> terminated by signal 7: Bus error

The usual cause of SIGBUS is a misaligned memory access on hardware
that's picky about that.  (Intel chips aren't, so that it's often
possible for such bugs to slip through developer testing.  But your
ARM system might be.)

Unfortunately, there's about zero chance of locating the bug from
the information you've provided.  What'd be helpful is to capture
stack traces from a few of the failed processes.  See

https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_=
backend

for directions.  Please try to get traces from both the SIG7 and
SIG11 cases, as it's not very clear whether they have the same
root.

			regards, tom lane