From: | 章晨曦(at)易景科技 <zhangchenxi(at)halodbtech(dot)com> |
---|---|
To: | Junwang Zhao <zhjwpku(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Re: Re: transaction lost when delete clog file after normal shutdown |
Date: | 2024-12-23 06:26:44 |
Message-ID: | tencent_45297262439D92D8680D2C4D@qq.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
But think about such a scenario, after INSERT some tuples, and COMMIT also succeed.
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.
Is there any chance to improve this?
Junwang Zhao<zhjwpku(at)gmail(dot)com> 在 2024年12月23日 周一 13:53 写道:
On Mon, Dec 23, 2024 at 1:43 PM 章晨曦(at)易景科技 <zhangchenxi(at)halodbtech(dot)com> wrote:
>
> Yes, i think you're right. The tuple will be set to HEAP_XMIN_COMMITTED when doing the visibility checking, but don't you think it's a little weird? Or may cause some confusion?
This is kind of an optimization, when there are lots of modifications
in a single
transaction, we don't know the transaction status until the last commit/abort,
we only need to do one write to clog instead of updating the visibility info of
all tuples, so no need to bookkeeping all the modified tuples somewhere.
From | Date | Subject | |
---|---|---|---|
Next Message | wenhui qiu | 2024-12-23 06:35:04 | Re: PoC: history of recent vacuum/checkpoint runs (using new hooks) |
Previous Message | Hayato Kuroda (Fujitsu) | 2024-12-23 06:14:49 | RE: Conflict detection for update_deleted in logical replication |