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.
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 |