From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | 章晨曦(at)易景科技 <zhangchenxi(at)halodbtech(dot)com> |
Cc: | Junwang Zhao <zhjwpku(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: transaction lost when delete clog file after normal shutdown |
Date: | 2024-12-23 06:50:17 |
Message-ID: | 1274894.1734936617@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"=?utf-8?B?56ug5pmo5pumQOaYk+aZr+enkeaKgA==?=" <zhangchenxi(at)halodbtech(dot)com> writes:
> And after a while, a system error occurred and unfortunately, just caused clog file corrupted.
> So we need to restore the database from backup just because of the tiny clog file corrupted.
I'm not seeing a large difference between this complaint
and whining because Unix doesn't have a way to recover from
"sudo rm -rf /". clog is critical data: if you mess with
it you will destroy your database. It is not the only
critical data in the system, either.
> Is there any chance to improve this?
We're not in the business of building doubly- or triply-redundant
storage. The cost/benefit just isn't attractive for very many people.
If you don't trust your hardware, you can put your storage on RAID,
or replicate the database, etc. If you have a DBA who thinks it's
cool to remove files they don't understand the purpose of, the answer
is to fire that DBA.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-12-23 06:51:39 | Re: Fix a wrong comment in load_file() |
Previous Message | wenhui qiu | 2024-12-23 06:35:04 | Re: PoC: history of recent vacuum/checkpoint runs (using new hooks) |