From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Peter Smith <smithpb2250(at)gmail(dot)com>, "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-15 18:05:22 |
Message-ID: | CALDaNm27_7ZjeMfUMdzsEYNBO1VNZqE-oevcbNRy5BPHh83GtA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 13 Nov 2023 at 17:02, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Nov 10, 2023 at 7:26 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> >
> > Thanks for the comments, the attached v13 version patch has the
> > changes for the same.
> >
>
> +
> + ReplicationOriginNameForLogicalRep(subid, InvalidOid, originname,
> sizeof(originname));
> + originid = replorigin_by_name(originname, false);
> + replorigin_advance(originid, sublsn, InvalidXLogRecPtr,
> + false /* backward */ ,
> + false /* WAL log */ );
>
> This seems to update the origin state only in memory. Is it sufficient
> to use this here? Anyway, I think using this requires us to first
> acquire RowExclusiveLock on pg_replication_origin something the patch
> is doing for some other system table.
Added the lock.
The attached v14 patch at [1] has the changes for the same.
[1] - https://www.postgresql.org/message-id/CALDaNm20%3DBk_w9jDZXEqkJ3_NUAxOBswCn4jR-tmh-MqNpPZYw%40mail.gmail.com
Regards,
Vignesh
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2023-11-15 18:06:32 | Re: pg_upgrade and logical replication |
Previous Message | Andres Freund | 2023-11-15 18:04:33 | Re: Some performance degradation in REL_16 vs REL_15 |