From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_upgrade and logical replication |
Date: | 2023-11-03 10:45:45 |
Message-ID: | CALDaNm19aRGGjYokN=x1wo-QKY8hCgJW50GVFyfE6=J29Nf3_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2 Nov 2023 at 11:05, Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> ~~~
>
> 2c.
> In a recent similar thread [1], they chose to implement a guc_hook to
> prevent a user from overriding this via the command line option during
> the upgrade. Shouldn't this patch do the same thing, for consistency?
Added GUC hook for consistency.
> ~~~
>
> 2d.
> If you do implement such a guc_hook (per #2c above), then should the
> patch also include a test case for getting an ERROR if the user tries
> to override that GUC?
Added a test for the same.
We can use this patch if we are planning to go ahead with guc_hooks
for max_slot_wal_keep_size as discussed at [1].
The attached patch has the changes for the same.
Regards,
Vignesh
Attachment | Content-Type | Size |
---|---|---|
0001-Added-GUC-hook-for-max_logical_replication_workers.patch | text/x-patch | 5.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Xiang Gao | 2023-11-03 10:46:57 | RE: CRC32C Parallel Computation Optimization on ARM |
Previous Message | Mark Hills | 2023-11-03 10:17:48 | Regression on pg_restore to 16.0: DOMAIN not available to SQL function |