Re: [bug fix] Produce a crash dump before main() on Windows
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: [bug fix] Produce a crash dump before main() on Windows |
Дата | |
Msg-id | 20180718.131020.210526049.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [bug fix] Produce a crash dump before main() on Windows (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: [bug fix] Produce a crash dump before main() on Windows
|
Список | pgsql-hackers |
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...? regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: