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

On Sat, Aug 1, 2026 at 4:45 AM Jeff Davis <pgsql(at)j-davis(dot)com> 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.