On Sat, Aug 1, 2026 at 4:45 AM Jeff Davis <[email protected]> wrote: > > A question about Finding 5, which has two parts: > > (a) Disabling a SERVER subscription and dropping its user mapping in > one transaction makes the running worker exit with 'ERROR: user mapping > not found' > > (b) Rotating a live mapping via DROP+CREATE (separate commits) can > permanently disable the subscription if the worker rereads in the gap. > > I already published a patch for (a). > > Part (b) is about the definition of disable_on_error, which is > documented: > > "Specifies whether the subscription should be automatically disabled if > any errors are detected by subscription workers during data replication > from the publisher. The default is false." > > Finding 5 seems to interpret "during data replication" to mean > "conflict on the remote side", but not other kinds of errors. Is that > the right interpretation? Or should most kinds of errors result in the > subscription being disabled? >
As per my understanding, most kinds of errors result in the subscription being disabled. > Finding 5 frames DROP USER MAPPING + CREATE USER MAPPING (in different > commits) as something that should not cause the subscription to be > disabled. But if the DROP has happened and the CREATE has not, what > reason do we have to think the error is not permanent? > Right, that is possible. In such a scenario, the current behavior of the apply-worker appears okay to me. Anyway, the feature disable_on_error is for the user to evaluate/analyze the current ERROR and accordingly take the next action. In this case, she can enable the subscription again. > Or, perhaps these are just edge cases, and part (b) is not very > important? > I think so. We don't need to do anything for part (b). BTW, shall we add a detailed comment as to why we separate the load of connection info from other subscription parameters for future readers on the following lines: /* * Generate the connection string for a subscription. * * This is deliberately separate from GetSubscription() because resolving * conninfo for a server-based subscription has its own error paths (foreign * server USAGE, user mapping, ForeignServerConnectionString()). Keeping it * separate lets a caller load the subscription and decide whether a * connection is actually needed, and check things such as whether the * subscription is enabled, before risking those errors. Callers that never * connect thus never hit them, which matters during restore. -- With Regards, Amit Kapila.
