| From: | cca5507 <cca5507(at)qq(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, ocean_li_996 <ocean_li_996(at)163(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [BUG] Incorrect historic snapshot may be serialized to diskduring fast-forwarding |
| Date: | 2025-12-30 02:57:46 |
| Message-ID: | tencent_3E54BE10BD962F65480619CFEC40CFCE2105@qq.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
> While I agree with your analysis, I'm not sure what actual problems it
> could lead to in practice. Have you had a chance to reproduce this
> behavior by using DDLs instead of a user-catalog table?
I'm not sure if this can be reproduced by using DDLs, but I will try.
> IIUC the problem can occur if a transaction makes catalog changes and writes
> only NEW_CID WAL records without INVALIDATION WAL records.
+1
> However, I'm not sure there are such transactions in practice.
Maybe currently not, but what about future, I'm not sure yet.
> IIUC it would not be a problem in terms of logical decoding even if we
> don't include their XIDs to the snapshot if they change only user-catalog
> tables. 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.
Our current design of historic snapshot is to track all catalogs even if only a part
of them are useful for logical decoding. So I think this bug breaks our design even
if it's maybe ok in practice.
--
Regards,
ChangAo Chen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Álvaro Herrera | 2025-12-30 03:14:42 | Re: Implement waiting for wal lsn replay: reloaded |
| Previous Message | Naga Appani | 2025-12-30 02:57:11 | Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring |