From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea |
Date: | 2001-01-16 17:38:58 |
Message-ID: | 12894.979666738@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> writes:
>> Because I think turning an elog(ERROR) into a system-wide crash is
>> not a good idea ;-). If you are correct that this behavior
>> is necessary for WAL-related critical sections, then indeed we need
>> two kinds of critical sections, one that just holds off cancel/die
>> response and one that turns elog(ERROR) into a dangerous weapon.
>> I'm going to wait and see Vadim's response before I do anything ...
> I've tried to move "dangerous" ops with non-zero probability of
> elog(ERROR) (eg new file block allocation) out of crit sections.
> Anyway we need in ERROR-->STOP for safety when changes aren't logged.
Why is that safer than just treating an ERROR as an ERROR? It seems to
me there's a real risk of a crash/restart loop if we force a restart
whenever we see an xlog-related problem.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert E. Bruccoleri | 2001-01-16 18:27:28 | Performance degradation in PostgreSQL 7.1beta3 vs 6.5.3 |
Previous Message | Mikheev, Vadim | 2001-01-16 17:28:45 | RE: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea |