| From: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Thom Brown <thom(at)linux(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Antonin Houska <ah(at)cybertec(dot)at> |
| Subject: | RE: REPACK (CONCURRENTLY) can crash a logical decoding session |
| Date: | 2026-09-06 16:18:18 |
| Message-ID: | TY4PR01MB17718B0047C2D6C23E6F4A62694B32@TY4PR01MB17718.jpnprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi
On Saturday, September 5, 2026 3:17 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> I've attached the updated patches. I merged Antonin's two patches into one
> with some cosmetic changes and the 0002 patch fixes issue (2).
> Please review them.
Both fixes look good to me. Just one question for the 0002.
+ /*
+ * Ignore update records without a new tuple. This happens when the
+ * caller of heap_update() asked for the change not to be decoded, as
+ * REPACK (CONCURRENTLY) does for the transient heap.
+ */
+ if (!(xlrec->flags & XLH_UPDATE_CONTAINS_NEW_TUPLE))
+ return;
It seems to me that updates on catalog relations with no new tuple will also be
skipped after this patch. I think that's fine, but perhaps we could mention this
case in the comment to make the behavior clearer.
Best Regards,
Zhijie Hou
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ayush Tiwari | 2026-09-06 16:34:37 | Re: Stabilize recovery conflict stats checks in 031_recovery_conflict.pl |
| Previous Message | Tom Lane | 2026-09-06 15:48:12 | Re: Improving display of octal GUCs |