Re: Re: Re: transaction lost when delete clog file after normal shutdown
| От | 章晨曦@易景科技 |
|---|---|
| Тема | Re: Re: Re: transaction lost when delete clog file after normal shutdown |
| Дата | |
| Msg-id | tencent_45297262439D92D8680D2C4D@qq.com обсуждение исходный текст |
| Ответ на | transaction lost when delete clog file after normal shutdown ("章晨曦@易景科技" <zhangchenxi@halodbtech.com>) |
| Ответы |
Re: transaction lost when delete clog file after normal shutdown
|
| Список | 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@gmail.com> 在 2024年12月23日 周一 13:53 写道：
On Mon, Dec 23, 2024 at 1:43 PM 章晨曦@易景科技 <zhangchenxi@halodbtech.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.
>
> 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.
В списке pgsql-hackers по дате отправления: