| From: | "Haiyang Li" <mohen(dot)lhy(at)alibaba-inc(dot)com> |
|---|---|
| To: | "Michael Paquier" <michael(at)paquier(dot)xyz> |
| Cc: | "Xuneng Zhou" <xunengzhou(at)gmail(dot)com>, "pgsql-bugs" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #19109: catalog lookup with the wrong snapshot during logical decoding causes coredump |
| Date: | 2025-11-11 02:46:47 |
| Message-ID: | 3bb4539e-c342-4e15-94f1-803203f1072e.mohen.lhy@alibaba-inc.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
From:Michael Paquier <michael(at)paquier(dot)xyz> 2025-11-11日 10:12 wrote:
> That's unfortunate. Having a reproducible test case that works with
> upstream would speed up the analysis of the problem a lot.
Indeed. I can reproduce the core in original instance by using pg_logical_slot_peek_changes
fucntion. But I can’t reproduce in other new instances. I will try to reproduce this issue again later.
While debugging the original instance using gdb, I found that txn 10722 was skipped due to
SnapBuildCurrentState(builder) < SNAPBUILD_FULL_SNAPSHOT, causing the catalog snapshot
to miss its commit. This suggests that the root cause may be in the new transaction handling
logic during snapshot building.
Regards,
Haiyang Li
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2025-11-11 03:39:17 | Re: [EXTERNAL]Re: BUG #19094: select statement on postgres 17 vs postgres 18 is returning different/duplicate results |
| Previous Message | Michael Paquier | 2025-11-11 02:12:17 | Re: BUG #19109: catalog lookup with the wrong snapshot during logical decoding causes coredump |