Re:logical decoding: skip unnecessary snapshot distribution.

From: 杨伯宇(长堂) <yangboyu(dot)yby(at)alibaba-inc(dot)com>
To: "shihao zhong" <zhong950419(at)gmail(dot)com>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re:logical decoding: skip unnecessary snapshot distribution.
Date: 2026-10-16 03:01:59
Message-ID: 6cf60dd4-49d9-4ae1-9ff8-cf203e65f1b4.yangboyu.yby@alibaba-inc.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi shihao,

Thanks for the review. Attached is v2 of the patch.

> 1. InvalidationsTouchSharedCatalog() should switch on msg->id with a
> default: elog(ERROR, ...). A new message type would otherwise be
> silently treated as "not shared". The SHAREDINVALSMGR_ID branch is
> dead code.

Yes, I choose a if-else style which follows the LocalExecuteInvalidationMessage().

> 2. The dbId test contradicts DecodeTXNNeedSkip() just below, which
> treats InvalidOid as "don't assume another database".

Yes, (dbId == InvalidOid) is now excluded.

> 3. "distribute" controls both the rebuild and the distribution; please
> rename or split it, and put the justification in a comment rather
> than only in the commit message.

"distribute" is renamed to "catalog_changes_relevant" to express the exact
meaning. Also, the code to "build a historic snapshot" in SnapBuildCommitTxn()
is now fully controlled by catalog_changes_relevant. I think this is clearer way.

> 4. Tests: a TAP test with two databases doing shared-catalog DDL in db2
> while a transaction is in progress in db1, plus Shlok's savepoint
> case.

A new test is added.

Regards,
Boyu Yang

Attachment Content-Type Size
v2-0001-logical-decoding-skip-snapshot-distribution.patch application/octet-stream 15.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shihao zhong 2026-10-16 03:05:06 Re: [PG19] pg_dump --statistics restores extended statistics by attribute number
Previous Message shihao zhong 2026-10-16 03:00:12 Re: Weird usages of sentinel_ok()