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

From Nikhil Sontakke
Subject Re: [HACKERS] logical decoding of two-phase transactions
Date
Msg-id CAMGcDxc3sc-C928toHEvj2dH9t=wTP=BZwUv3rE1bnHzTr9R6Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] logical decoding of two-phase transactions  (Nikhil Sontakke <nikhils@2ndquadrant.com>)
Responses Re: [HACKERS] logical decoding of two-phase transactions
List pgsql-hackers
>> This is due to the new ERROR handling code that I added today for the
>> lock/unlock APIs. Will fix.
>>
>
> Fixed. I continue to test this area for other issues.
>

Revised the patch after more testing and added more documentation in
the ERROR handling code path.

I tested ERROR handling by ensuring that LogicalLock is held by
multiple backends and induced ERROR while holding it. The handling in
ProcKill rightly removes entries from these backends as part of ERROR
cleanup. A future ROLLBACK removes the only one entry belonging to the
Leader from the decodeGroup appropriately later. Seems to be holding
up ok

Had also missed out a new test file for the option 0005 patch earlier.
That's also included now.

Regards,
Nikhils
-- 
 Nikhil Sontakke                   http://www.2ndQuadrant.com/
 PostgreSQL/Postgres-XL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Optimize Arm64 crc32c implementation in Postgresql
Next
From: Thomas Munro
Date:
Subject: Re: Optimize Arm64 crc32c implementation in Postgresql