Re: [HACKERS] logical decoding of two-phase transactions - Mailing list pgsql-hackers

From Peter Smith
Subject Re: [HACKERS] logical decoding of two-phase transactions
Date
Msg-id CAHut+Ptd3Z4c7OtKO=_7kX09Kk4tn=1=2xA60T_hGrXF95-D9A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] logical decoding of two-phase transactions  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: [HACKERS] logical decoding of two-phase transactions
List pgsql-hackers
Please find attached the latest patch set v70*

Differences from v69* are:

* Rebased to HEAD @ today
Unfortunately, the v69 patch was broken due to a recent push [1]

----
[1] https://github.com/postgres/postgres/commit/82ed7748b710e3ddce3f7ebc74af80fe4869492f

Kind Regards,
Peter Smith.
Fujitsu Australia

On Wed, Apr 7, 2021 at 10:25 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> Please find attached the latest patch set v69*
>
> Differences from v68* are:
>
> * Rebased to HEAD @ yesterday.
> There was some impacts caused by recently pushed patches [1] [2]
>
> * The stream/prepare functionality and tests have been restored to be
> the same as they were in v48 [3].
> Previously, this code had been removed back in v49 [4] due to
> incompatibilities with the (now obsolete) psf design.
>
> * TAP tests are now co-located in the same patch as the code they are testing.
>
> ----
> [1] https://github.com/postgres/postgres/commit/531737ddad214cb8a675953208e2f3a6b1be122b
> [2] https://github.com/postgres/postgres/commit/ac4645c0157fc5fcef0af8ff571512aa284a2cec
> [3] https://www.postgresql.org/message-id/CAHut%2BPsr8f1tUttndgnkK_%3Da7w%3Dhsomw16SEOn6U68jSBKL9SQ%40mail.gmail.com
> [4] https://www.postgresql.org/message-id/CAFPTHDZduc2fDzqd_L4vPmA2R%2B-e8nEbau9HseHHi82w%3Dp-uvQ%40mail.gmail.com
>
> Kind Regards,
> Peter Smith.
> Fujitsu Australia
>
> On Tue, Mar 30, 2021 at 11:03 AM Peter Smith <smithpb2250@gmail.com> wrote:
> >
> > Please find attached the latest patch set v68*
> >
> > Differences from v67* are:
> >
> > * Rebased to HEAD @ today.
> >
> > * v68 fixes an issue reported by Vignesh [1] where a scenario was
> > found which still was able to cause a generated GID clash. Using
> > Vignesh's test script I could reproduce the problem exactly as
> > described. The fix makes the GID unique by including the subid. Now
> > the same script runs to normal completion and produces good/expected
> > output:
> >
> >  transaction |       gid        |           prepared            |
> > owner   | database
> > -------------+------------------+-------------------------------+----------+----------
> >          547 | pg_gid_16389_543 | 2021-03-30 10:32:36.87207+11  |
> > postgres | postgres
> >          555 | pg_gid_16390_543 | 2021-03-30 10:32:48.087771+11 |
> > postgres | postgres
> > (2 rows)
> >
> >
> > ----
> > [1]
https://www.postgresql.org/message-id/CALDaNm2ZnJeG23bE%2BgEOQEmXo8N%2Bfs2g4%3DxuH2u6nNcX0s9Jjg%40mail.gmail.com
> >
> > Kind Regards,
> > Peter Smith.
> > Fujitsu Australia

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Can we remove extra memset in BloomInitPage, GinInitPage and SpGistInitPage when we have it in PageInit?
Next
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Disable WAL logging to speed up data loading