From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | wobbet(at)wobbet(dot)com, Robert Sanford <wobbet(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18076: Consistently receiving Signal 7 and Signal 11 errors |
Date: | 2023-08-30 13:25:51 |
Message-ID: | 169801.1693401951@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Robert Sanford <wobbet(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2023-08-30 16:31:46 | Re: BUG #18075: configuration variable idle_session_timeout not working as expected |
Previous Message | Richard Guo | 2023-08-30 12:03:55 | Re: BUG #18077: PostgreSQL server subprocess crashed by a SELECT statement with WITH clause |