From: | "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com> |
---|---|
To: | 'Peter Smith' <smithpb2250(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Ajin Cherian <itsajin(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: [HACKERS] logical decoding of two-phase transactions |
Date: | 2021-02-26 14:53:58 |
Message-ID: | OSBPR01MB48885929127F2E006C5E407EED9D9@OSBPR01MB4888.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
On Thursday, February 25, 2021 4:02 PM Peter Smith <smithpb2250(at)gmail(dot)com>
> Please find attached the latest patch set v43*
>
> - Added new patch 0007 "Fix apply worker prepare" as discussed here [2]
>
> [2]
> https://www.postgresql.org/message-id/CAA4eK1L%3DdhuCRvyDvrXX5wZ
> gc7s1hLRD29CKCK6oaHtVCPgiFA%40mail.gmail.com
I tested the scenario that
we resulted in skipping prepared transaction data and
the replica became out of sync, which was described in [2].
And, as you said, the problem is addressed in v43.
I used twophase_snapshot.spec as a reference
for the flow (e.g. how to make a consistent snapshot
between prepare and commit prepared) and this time,
as an alternative of the SQL API(pg_create_logical_replication_slot),
I issued CREATE SUBSCRIPTION, and other than that,
I followed other flows in the spec file mainly.
I checked that the replica has the same data at the end of this test,
which means the mechanism of spoolfile works.
Best Regards,
Takamichi Osumi
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-02-26 15:11:57 | Re: Postgresql network transmission overhead |
Previous Message | Dilip Kumar | 2021-02-26 14:40:29 | Re: [HACKERS] Custom compression methods |