Re: BUG #18280: logical decoding build wrong snapshot for subtransactions

From: feichanghong <feichanghong(at)qq(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #18280: logical decoding build wrong snapshot for subtransactions
Date: 2024-01-24 11:01:44
Message-ID: tencent_D07767F0078E09240737829D12D97B530606@qq.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Thank you for your correction.

> On Jan 24, 2024, at 17:18, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> While looking closely at the test result, I wondered how the following
> part of test "s0_begin" "s0_truncate" "s1_checkpoint" "s1_get_changes"
> "s0_insert_part" "s1_get_changes" "s0_commit" can see the insert when
> the containing transaction is not yet committed. Then, I found it is
> because the insert is performed from session 1 due to way it is
> declared.
>
> session "s1"
> ...
> step "s1_get_changes" { SELECT data FROM
> pg_logical_slot_get_changes('isolation_slot', NULL, NULL,
> 'skip-empty-xacts', '1', 'include-xids', '0'); }
> +step "s0_insert_part" { INSERT INTO tbl1_part VALUES (1); }
>
> I think this session should be performed from seesion-1 and we need
> one more get_changes() call to see the problem. I have modified the
> test accordingly and also changed the comments. See the attached and
> let me know what you people think.

I'm very sorry for confusing you due to my mistake. In my original patch,
"s0_insert_part" should be "s1_insert_part" in session "s1", and after
confirmation, the problem can be reproduced.
Of course your fix is totally correct for me.

Best Regards,
Fei Changhong
Alibaba Cloud Computing Ltd.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2024-01-24 12:00:01 BUG #18309: TOASTed entry in pg_subscription provokes an assertion failure
Previous Message gparc 2024-01-24 10:11:17 Re: BUG #18295: In PostgreSQL a unique index on targeted columns is sufficient to support a foreign key