> On Jun 17, 2021, at 9:47 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> (a) The patch
> seem to be assuming that the error can happen only by the apply worker
> but I think the constraint violation can happen via one of the table
> sync workers as well
You are right. Peter mentioned the same thing, and it is clearly so. I am working to repair this fault in v2 of the
patch.
> (b) What happens if the error happens when you
> are updating the error information in the catalog table.
I think that is an entirely different kind of error. The patch attempts to catch errors caused by the user, not by
corefunctionality of the system failing. If there is a fault that prevents the catalogs from being updated, it is
unclearwhat the patch can do about that.
> I think
> instead of seeing the actual apply time error, the user might see some
> other for which it won't be clear what is an appropriate action.
Good point.
Before trying to do much of anything with the caught error, the v2 patch logs the error. If the subsequent efforts to
disablethe subscription fail, at least the logs should contain the initial failure message. The v1 patch emitted a log
messagemuch further down, and really just intended for debugging the patch itself, with many opportunities for
somethingelse to throw before the log is written.
> We are also discussing another action like skipping the apply of the
> transaction on an error [1]. I think it is better to evaluate both the
> proposals as one seems to be an extension of another.
Thanks for the link.
I think they are two separate options. For some users and data patterns, subscriber-side skipping of specific
problematiccommits will be fine. For other usage patterns, skipping earlier commits will results in more and more data
integrityproblems (foreign key references, etc.) such that the failures will snowball with skipping becoming the norm
ratherthan the exception. Users with those usage patterns would likely prefer the subscription to automatically be
disableduntil manual intervention can clean up the problem.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
