| From: | vignesh C <vignesh21(at)gmail(dot)com> |
|---|---|
| To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
| Cc: | Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Include sequences in publications created by pg_createsubscriber |
| Date: | 2026-07-01 07:21:14 |
| Message-ID: | CALDaNm0F9oX18eH5MbNRWS5uux2KneDc2RwX__+7vm7nvgHsXg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 1 Jul 2026 at 08:17, Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> A review comment for patch v5-0001
>
> ======
> doc/src/sgml/ref/pg_createsubscriber.sgml
>
> 1.
> + replica from a physical standby server. By default,
> + <application>pg_createsubscriber</application> configures
> + <link linkend="logical-replication">logical replication</link> by
> + automatically creating internal publication and subscription objects. In
> + this mode, a publication and subscription are created for each database, and
> + the publications include all tables and sequences in their respective
> + databases. When user-specified publications are used, the subscriptions
> + replicate only the objects included in those publications. It must be run at
> + the target server.
>
> In that last sentence, I felt it might be better to avoid saying "It"
> which could be misunderstood as referring to something other than the
> tool itself.
>
> BEFORE
> It must be run at the target server.
> SUGGESTION
> <application>pg_createsubscriber</application> must be run at the target server.
The attached v6 version patch has the changes for the same.
Regards,
Vignesh
| Attachment | Content-Type | Size |
|---|---|---|
| v6-0001-Include-sequences-in-publications-created-by-pg_c.patch | application/octet-stream | 8.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dean Rasheed | 2026-07-01 07:28:07 | Re: Global temporary tables |
| Previous Message | cca5507 | 2026-07-01 07:21:06 | Re: Handle concurrent drop when doing whole database vacuum |