At Wed, 18 Jul 2018 11:12:06 +0800, Craig Ringer <craig@2ndquadrant.com> wrote in <CAMsr+YHv0KfWhA+Z=UVydpvLQ-QyLaidBqpHxQ=YqTPiDGG6dg@mail.gmail.com> > On 26 February 2018 at 12:06, Tsunakawa, Takayuki < > tsunakawa.takay@jp.fujitsu.com> wrote: > > > From: Craig Ringer [mailto:craig@2ndquadrant.com] > > > The patch proposed here means that early crashes will invoke WER. If > > we're > > > going to allow WER we should probably just do so unconditionally. > > > > > > I'd be in favour of leaving WER on when we find out we're in a > > noninteractive > > > service too, but that'd be a separate patch for pg11+ only. > > > > 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. > > > > Yeah, that's quite old and dates back to when Windows didn't offer much if > any control over WER in services.
Yeah. If we want to take a crash dump, we cannot have auto-restart. Since it is inevitable what we can do for this would be adding a new knob for that, which cannot be turned on together with restart_after_crash...?
Why?
Mind you, I don't much care about restart_after_crash, I think it's thoroughly obsolete. Windows has been capable of restarting failed services forever, and systemd does so too. There's little reason to have postgres try to do its own self-recovery now, and I prefer to disable it so the postmaster can cleanly exit and get a fresh new launch.
