From: | Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ajin Cherian <itsajin(at)gmail(dot)com> |
Subject: | Re: [PATCH] add concurrent_abort callback for output plugin |
Date: | 2021-03-26 09:12:54 |
Message-ID: | 4b7caf85-fea9-d146-4c4c-6cf53bb68982@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 26.03.21 04:28, Amit Kapila wrote:
> I think as you have noted that stream_abort or rollback_prepared will
> be sent (the remaining changes in-between will be skipped) as we
> decode them from WAL
Yes, but as outlined, too late. Multiple other transactions may get
decoded until the decoder reaches the ROLLBACK PREPARED. Thus,
effectively, the output plugin currently needs to deduce that a
transaction got aborted concurrently from one out of half a dozen other
callbacks that may trigger right after that transaction, because it will
only get closed properly much later.
> so it is not clear to me how it causes any delays
> as opposed to where we don't detect concurrent abort say because after
> that we didn't access catalog table.
You're assuming very little traffic, where the ROLLBACK ABORT follows
the PREPARE immediately in WAL. On a busy system, chances for that to
happen are rather low.
(I think the same is true for streaming and stream_abort being sent only
at the time the decoder reaches the ROLLBACK record in WAL. However, I
did not try. Unlike 2PC, where this actually bit me.)
Regards
Markus
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2021-03-26 09:20:14 | Walsender may fail to send wal to the end. |
Previous Message | Fujii Masao | 2021-03-26 08:46:03 | Re: Is it useful to record whether plans are generic or custom? |