Re: BUG #17636: terminating connection because of crash of another server process - Mailing list pgsql-bugs

From Julien Rouhaud
Subject Re: BUG #17636: terminating connection because of crash of another server process
Date
Msg-id 20221017034928.z24ugv6t2upbqknw@jrouhaud
Whole thread Raw
In response to BUG #17636: terminating connection because of crash of another server process  (PG Bug reporting form <noreply@postgresql.org>)
Responses RE: BUG #17636: terminating connection because of crash of another server process
List pgsql-bugs
Hi,

On Wed, Oct 12, 2022 at 11:22:26AM +0000, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference:      17636
> Logged by:          Sujeet Swaminath
> Email address:      sujeet.chaurasia@lisec.com
> PostgreSQL version: 12.11
> Operating system:   Windows
> Description:
>
> We are facing this issue with POSTGRES 12.11, only on windows OS, with Linux
> OS, it works fine,
>
> if the executable that is using the database session crashes, then the
> entire database goes to recovery mode and restarts, in the Postgres log, we
> can find the below messages.
>
> "2022-10-06 17:44:09.210 CEST [8860] LOG:  server process (PID 9980) exited
> with exit code 0
> 2022-10-06 17:44:09.210 CEST [8860] LOG:  terminating any other active
> server processes
>
> 2022-10-06 17:44:09.211 CEST [9992] WARNING:  terminating the connection
> because of the crash of another server process
>
> 2022-10-06 17:44:09.211 CEST [9992] DETAIL:  The postmaster has commanded
> this server process to roll back the current transaction and exit because
> another server process exited abnormally and possibly corrupted shared
> memory.
>
> 2022-10-06 17:44:09.211 CEST [9992] HINT:  In a moment you should be able to
> reconnect to the database and repeat your command. "

This unfortunately isn't enough information to understand what's going on.

First, is the problem still happening if you update to version 12.12?

Also, do you have any extension or modules configured?  You haven't shown the
logs corresponding to the original process problem, including the query it was
executing in case of a normal backend.

Can you manually reproduce the problem, and/or get a stack trace of the
problem?  See
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
(and possibly

https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows#Using_crash_dumps_to_debug_random_and_unpredictable_backend_crashes)
for more details on how to do.



pgsql-bugs by date:

Previous
From: Facundo Etchezar
Date:
Subject: Re: BUG #17637: case-when branches taken even if they dont match, raising errors
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: WAL segments removed from primary despite the fact that logical replication slot needs it.