Re: [bug fix] Produce a crash dump before main() on Windows

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Cc: 'Craig Ringer' <craig(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [bug fix] Produce a crash dump before main() on Windows
Date: 2018-07-23 07:21:30
Message-ID: 20180723072130.GK2854@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On Mon, Feb 26, 2018 at 04:06:48AM +0000, Tsunakawa, Takayuki wrote:
> As for PG11+, I agree that we want to always leave WER on. That is,
> call SetErrorMode(SEM_FAILCRITICALERRORS) but not specify
> SEM_NOGPFAULTERRORBOX. The problem with the current specification of
> PostgreSQL is that the user can only get crash dumps in a fixed folder
> $PGDATA\crashdumps. That location is bad because the crash dumps will
> be backed up together with the database cluster without the user
> noticing it. What's worse, the crash dumps are large. With WER, the
> user can control the location and size of crash dumps.

I have not looked by myself at the problems around WER and such so I
don't have a clear opinion, but including crash dumps within backups is
*bad*. We have a set of filtering rules in basebackup.c and pg_rewind
since v11, we could make use of it and remove all contents from
crashdumps/ from what gets backed up or rewound. excludeDirContents
creates empty folders when those are listed, so we'd want to not create
an empty folder in Windows backups, which makes a bit more more
difficult.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-07-23 07:26:35 Re: [bug fix] Produce a crash dump before main() on Windows
Previous Message Kyotaro HORIGUCHI 2018-07-23 07:16:18 Re: [HACKERS] Restricting maximum keep segments by repslots