| From: | ocean_li_996 <ocean_li_996(at)163(dot)com> |
|---|---|
| To: | cca5507 <cca5507(at)qq(dot)com> |
| Cc: | "Masahiko Sawada" <sawada(dot)mshk(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [BUG] Incorrect historic snapshot may be serialized to disk during fast-forwarding |
| Date: | 2026-01-27 07:18:58 |
| Message-ID: | 5a24c4b6.363.19bfe51e2f8.Coremail.ocean_li_996@163.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Masahiko, ChangAo,
Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> 2025-12-30 01:10:01 wrote:
> It might be more future proof to mark transactions as catalog-changed
> even when fast-forwarding a NEW_CID record, as you proposed, but I'd
> like to confirm the actual problems first.
Yeah, I haven’t identified any actual issue in practice. My observations are
purely based on code-level logic analysis.
cca5507 <cca5507(at)qq(dot)com> Sat, 17 Jan 2026 23:56:17 +0800 wrote:
> The commit message of 'user_catalog_table' says:
>
> ```
> Replication solutions built around the logical decoding machinery
> will likely need to set this operation for their configuration
> tables; it might also be needed by extensions which perform table
> access in their output functions.
> ```
>
> So if there is an extension using the incorrect snapshot to scan user
> catalog tables, it will get the wrong result, right?
I agree with your analysis. The introduction of user_catalog_table is intended to
ensure that the historical MVCC in logical replication can observe the historical
state of this table. Consequently, transactions on this table should be tracked by
the historical snapshot — even while in the fast forward state.
Regards
Haiyang Li
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Xuneng Zhou | 2026-01-27 07:23:50 | Add pg_stat_recovery system view |
| Previous Message | Richard Guo | 2026-01-27 07:10:07 | Re: Optimize IS DISTINCT FROM with non-nullable inputs |