Re: [BUG] Incorrect historic snapshot may be serialized to diskduring fast-forwarding

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

In response to

Browse pgsql-hackers by date

  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