On Thu, Jan 27, 2022 at 2:15 PM Andres Freund <andres@anarazel.de> wrote:
Another related thing is that using a 32bit xid for allowing skipping is a bad idea anyway - we shouldn't adding new interfaces with xid wraparound dangers - it's getting more and more common to have multiple wraparounds a day. An easily better alternative would be the LSN at which a transaction starts.
Interesting idea. I do not think a well-designed skipping feature need worry about wrap-around though. The XID to be skipped was just seen be a worker and because it failed it will continue to be the same XID encountered by that worker until it is resolved. There is no effective progression in time while the subscriber is stuck for wrap-around to happen. Since we want to skip the transaction as a whole adding a layer of hidden indirection to the process seems undesirable. I'm not against the idea though - to the user it is basically "copy this value from the error message in order to skip the transaction that caused the error". Then the system verifies the value and then ensures it skips one, and only one, transaction.
It's pretty easy from the POV of getting into a new transaction.
PG_CATCH():
/* get us out of the failed transaction */ AbortOutOfAnyTransaction();
StartTransactionCommand(); /* do something to remember the error we just got */ CommitTransactionCommand();
Thank you.
It may be a bit harder to afterwards to to not just error out the whole worker, because we'd need to know what to do instead.
I imagine the launcher and worker startup code can be made to deal with the restart adequately. Just wait if the last thing seen was an error. Require the user to manually resume the worker - unless we really think a try-until-you-succeed with a backoff protocol is superior. Upon system restart all error information is cleared and we start from scratch and let the errors happen (or not depending) as they will.
