Re: BUG #17636: terminating connection because of crash of another server process
От | Julien Rouhaud |
---|---|
Тема | Re: BUG #17636: terminating connection because of crash of another server process |
Дата | |
Msg-id | 20221103060311.6bl4uioi5n3nlr5a@jrouhaud обсуждение исходный текст |
Ответ на | RE: BUG #17636: terminating connection because of crash of another server process (Chaurasia Sujeet <Sujeet.Chaurasia@lisec.com>) |
Список | 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 по дате отправления: