Re: CREATE SUBSCRIPTION ... SERVER vs. pg_dump, etc.

On Fri, 2026-07-10 at 12:59 -0700, Noah Misch wrote:
> An Opus 4.8 review of commit 8185bb5 found two pg_dump+restore
> failure
> scenarios, visible in the attached test patch.  (The patch also tests
> a
> REASSIGN OWNED finding, for which I started a distinct thread
> postgr.es/m/flat/20260710192533(dot)4f(dot)noahmisch(at)microsoft(dot)com).
>
> Opus also emitted the attached report about these findings and
> others.  I
> didn't examine the others closely.  Finding-19, about invalidation
> callbacks,
> stood out as perhaps most exciting if true.

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?

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? If it's an
administrative rotation of some kind, why not alter-in-place or wrap it
in a transaction?

Or, perhaps these are just edge cases, and part (b) is not very
important?

Regards,
Jeff Davis