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 20221103060311.6bl4uioi5n3nlr5a@jrouhaud
Whole thread Raw
In response to RE: BUG #17636: terminating connection because of crash of another server process  (Chaurasia Sujeet <Sujeet.Chaurasia@lisec.com>)
List pgsql-bugs
On Wed, Nov 02, 2022 at 07:13:29AM +0000, Chaurasia Sujeet wrote:
>
> We've upgraded postgres to postgres13, and no extension is configured in
> postgresql on the server, Yet it again crashed again, and there is no
> antivirus on the server.
>
> Since the problem happens randomly and we are not able to recreate the
> problem ourselves. and the log shows no query or details as to what caused
> the crash. we just get a message that one PID of postgres.exe exited with
> code 0, which makes it difficult to even troubleshoot.
>
> According to the article you shared, we set up the minidump for the random
> crash, but we didn't find the dump in the crashdumps directory.
>
> We followed the highlighted part below from this article, as the crash dump
> handler is already included in the postgresql as per the article. so any
> crash dump should get generated in the crashdumps directory.
>
>
> If the crashes appear to be random and you don't know how to trigger them,
> it's hard to connect a debugger to the problem postgres.exe before it
> crashes.  Setting your debugger as the JIT (just-in-time) or post-mortem
> debugger won't help you, because PostgreSQL generally runs as a service under
> a different user account that cannot interact with the desktop. You could
> always initdb a new cluster under your normal user account and use pg_ctl to
> start the postmaster with that cluster manually, so you can JIT debug under
> your own user account where Pg can interact with the desktop. This isn't
> suitable for production use, though, and you might not be able to reproduce
> the problem that way.  In PostgreSQL 9.0 and above there is a crash dump
>
hander<http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/port/win32/crashdump.c;h=7550fa6f26b82d6fc41f5f68afb35ec44d25d00b;hb=HEAD>
> included in PostgreSQL. To use it: *       Create a directory named
> crashdumps (all lower case) in the PostgreSQL data directory (as shown by
> SHOW data_directory; in psql) *       Give the PostgreSQL user (postgres by
> default) "full control" of it in the security tab of the folder properties *
> Run the problem code. You don't need to restart Pg or change any settings.  *
> When a backend crashes, a Windows minidump should be created in the
> crashdumps directory.
>
>
> Please help us to know if there is any other step here to generate a crash
> dump as the issue is random and we are not aware of the cause that is making
> postgres.exe crash.

Unfortunately I'm not a Windows user myself, so I have no idea how to generate
a coredump on that platform.  If the instructions on the wiki don't work, and
since no one seemed to show up with an answer, maybe ask Microsoft or on a
Windows dedicated forum.



pgsql-bugs by date:

Previous
From: Noah Misch
Date:
Subject: Re: pg_upgrade fails if privileges have been granted on pg_start_backup()/pg_stop_backup() in the old cluster
Next
From: PG Bug reporting form
Date:
Subject: BUG #17676: Text comparison appears to be wrong