Amit Kapila <amit.kapil...@gmail.com> writes:
> On Tue, Aug 20, 2024 at 2:01 PM shveta malik <shveta.ma...@gmail.com> wrote:
>> Looks good to me. Please find backported patches attached.
> Pushed.
I came across this commit while preparing release notes, and I'm
worried about whether it doesn't create more problems than it solves.
The intent stated in the thread subject is to prevent an apply worker
from advancing past a prepared transaction if the subscriber side
doesn't permit prepared transactions. However, it appears to me that
the committed patch doesn't permit an apply worker to advance past
any failing transaction whatsoever. Was any thought given to how
a DBA would get out of such a situation and get replication flowing
again? In the prepared-xact case, it's at least clear that you
could increase max_prepared_transactions and restart the subscriber
installation. In the general case, it's not very obvious that you'd
even know what the problem is let alone have an easy way to fix it.
In other words: I thought the original design here was to
intentionally ignore apply errors and keep going, on the theory that
that was better than blocking replication altogether. This commit
has reversed that decision, on the strength of little or no
discussion AFAICS. Are we really ready to push this into minor
releases of stable branches? Is it a good idea even on HEAD?
regards, tom lane
