Re: [HACKERS] logical decoding of two-phase transactions
От | Peter Smith |
---|---|
Тема | Re: [HACKERS] logical decoding of two-phase transactions |
Дата | |
Msg-id | CAHut+Ptd3Z4c7OtKO=_7kX09Kk4tn=1=2xA60T_hGrXF95-D9A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] logical decoding of two-phase transactions (Peter Smith <smithpb2250@gmail.com>) |
Ответы |
Re: [HACKERS] logical decoding of two-phase transactions
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: