From: | Shubham Khanna <khannashubham1197(at)gmail(dot)com> |
---|---|
To: | vignesh C <vignesh21(at)gmail(dot)com> |
Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility. |
Date: | 2024-12-11 10:05:32 |
Message-ID: | CAHv8RjLa_XEtiuaPHHZOk6LBE=X+4kuiH1_zq0PYuZGGX3Kqig@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 11, 2024 at 2:08 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Wed, 11 Dec 2024 at 11:21, Shubham Khanna
> <khannashubham1197(at)gmail(dot)com> wrote:
> >
> > On Wed, Dec 11, 2024 at 4:21 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> >
> > I have fixed the given comments. The attached patch contains the
> > suggested changes.
>
> Since all the subscriptions are created based on the two_phase option
> provided, there is no need to store this for each database:
> @@ -53,6 +54,7 @@ struct LogicalRepInfo
> char *pubname; /* publication name */
> char *subname; /* subscription name */
> char *replslotname; /* replication slot name */
> + bool two_phase; /* two-phase enabled
> for the subscription */
>
> dbinfo[i].dbname = cell->val;
> + dbinfo[i].two_phase = opt->two_phase;
> if (num_pubs > 0)
>
> How about we handle something like in the attached changes.
>
Thank you for pointing this out and for suggesting the changes. I
agree with your approach.
Also, I found a mistake in getopt_long and fixed it in this version of
the patch.
The attached patch contains the suggested changes.
Thanks and regards,
Shubham Khanna.
Attachment | Content-Type | Size |
---|---|---|
v4-0001-Add-support-for-two-phase-commit-in-pg_createsubs.patch | application/octet-stream | 10.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2024-12-11 10:09:49 | Re: pg_dump memory leak of 400 bytes |
Previous Message | Oleg Tselebrovskiy | 2024-12-11 09:59:49 | pg_dump memory leak of 400 bytes |