From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 20:51:21 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A234D3284@sectorbase1.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > 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.
Why don't we elog(ERROR) in assert checking but abort?
Consider elog(STOP) on any errors inside critical sections
as assert checking. Rule is simple - validate operation before
applying it to permanent storage - and it's better to force
any future development to follow this rule by any means.
It's very easy to don't notice ERROR - it's just transaction
abort and transaction abort is normal thing, - but errors inside
critical sections are *unexpected* things which mean that something
totally wrong in code.
As for crash/restart loop, Hiroshi rised this issue ~month ago and I
was going to avoid elog(STOP) in AM-specific redo functions and do
elog(LOG) instead, wherever possible, but was busy with CRC/backup stuff
- ok, I'll look there soon.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-01-16 21:11:49 | Re: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea |
Previous Message | Mikheev, Vadim | 2001-01-16 19:36:20 | RE: CRCs |