| From: | Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Ajin Cherian <itsajin(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] add concurrent_abort callback for output plugin |
| Date: | 2021-03-30 09:54:31 |
| Message-ID: | fe828aae-e837-dac2-8e48-1a821b3a1010@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 30.03.21 11:02, Amit Kapila wrote:
> On Tue, Mar 30, 2021 at 12:00 PM Markus Wanner
>> Yes, this replaces the PREPARE I would do from the concurrent_abort
>> callback in a direct call to rb->prepare.
>
> Because concurrent_abort()
> internally trying to prepare transaction seems a bit ugly and not only
> that if we want to go via that route, it needs to distinguish between
> rollback to savepoint and rollback cases as well.
Just to clarify: of course, the concurrent_abort callback only sends a
message to the subscriber, which then (in our current implementation)
upon reception of the concurrent_abort message opts to prepare the
transaction. Different implementations would be possible.
I would recommend this more explicit API and communication over hiding
the concurrent abort in a prepare callback.
Regards
Markus
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dean Rasheed | 2021-03-30 09:55:12 | Re: pgbench - add pseudo-random permutation function |
| Previous Message | Michael Paquier | 2021-03-30 09:53:49 | Re: Refactor SSL test framework to support multiple TLS libraries |