Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect
Chao Li <li.evan.chao@gmail.com>
From: Chao Li <li.evan.chao@gmail.com>
To: Japin Li <japinli@hotmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>,
Amit Kapila <amit.kapila16@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-23T08:45:56Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add TAP test for GUC settings passed via CONNECTION in logical replication.
- ec8d91c7e78c 15.16 landed
- 67edd54f0639 16.12 landed
- 358784645eb8 17.8 landed
- 6ec596815125 18.2 landed
- 5f13999aa11d 19 (unreleased) landed
-
Honor GUC settings specified in CREATE SUBSCRIPTION CONNECTION.
- f7eb44e0f087 15.16 landed
- 75f3428f2436 16.12 landed
- 7a990e801a72 17.8 landed
- 797fc5d1b38d 18.2 landed
- d926462d8190 19 (unreleased) landed
-
Ensure consistent logical replication of datetime and float8 values.
- f3d4019da5d0 15.0 cited
> On Dec 23, 2025, at 16:13, Japin Li <japinli@hotmail.com> wrote: > > On Tue, 23 Dec 2025 at 14:17, Chao Li <li.evan.chao@gmail.com> wrote: >>> On Dec 19, 2025, at 19:05, Fujii Masao <masao.fujii@gmail.com> wrote: >>> >>> On Fri, Dec 19, 2025 at 7:07 PM Japin Li <japinli@hotmail.com> wrote: >>>> Thanks for the patch — that was my oversight. >>>> >>>> LGTM with one small suggestion: >>> >>> Thanks for the review! >>> >>>> The comment says: "If the option is not found in connInfo, return NULL value." >>>> >>>> Since the parameter is named `keyword`, I'd suggest: "If the keyword is not found in connInfo, return NULL." >>>> >>>> This keeps terminology consistent with the function signature. >>> >>> I think "the option with the given keyword" is more precise than just >>> "the keyword". >>> That said, simply using "the option" also seems sufficient in this context... >>> >>> >>> Regarding 0002 patch, I found that it caused a CI failure, so I’ve updated >>> the patch to fix that. The revised patch is attached. >>> >>> Regards, >>> >>> -- >>> Fujii Masao >>> <v6-0001-PG15-PG16-Honor-GUC-settings-specified-in-CREATE-SUBSCRIPTI.txt><v6-0002-Add-TAP-test-for-GUC-settings-passed-via-CONNECTI.patch><v6-0001-Honor-GUC-settings-specified-in-CREATE-SUBSCRIPTI.patch> >> >> A few more comments on v6: >> >> 1 - 0001 >> ``` >> + if (opt != NULL) >> + pfree(opt); >> ``` >> >> From what I learned from previous reviews, pfree() is safe to handle NULL, we can omit the NULL check, which makes the code simpler. This comment applies to multiple places. >> > > I think we cannot omit it here. We have two pfree()s, one for frontend and > one for backend. IIUC, the frontend pfree() is safe to handle NULL, but the > backend pfree() is not. > Ahh… You are right. I just traced a backend pfree(), and it ends up calling GetMemoryChunkMethodID(const void *point), and the function doesn’t handle NULL pointer. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/