Обсуждение: pg_dump crash due to incomplete ordering of DO_SUBSCRIPTION_REL objects

Hi,

While verifying upgrade of subscriber instance, I noticed pg_dump
crash caused by incomplete sorting logic for DO_SUBSCRIPTION_REL
objects in DOTypeNameCompare(). When multiple subscription–relation
entries belong to the same subscription, the comparison does not
establish a complete ordering. In this case, the comparison falls
through to the generic assertion path. The attached patch fixes this
by extending the comparison for DO_SUBSCRIPTION_REL objects to include
deterministic ordering keys. After the subscription name comparison,
entries are ordered by the referenced table's schema name and then by
table name.

This issue has started failing after commit:
commit 0decd5e89db9f5edb9b27351082f0d74aae7a9b6
Sort dump objects independent of OIDs, for the 7 holdout object types.

This can be reproduced by having logical replication setup with
subscription subscribing to few tables.

Thanks,
Vignesh

On Mon, Dec 15, 2025 at 11:35:35PM +0530, vignesh C wrote:
> While verifying upgrade of subscriber instance, I noticed pg_dump
> crash caused by incomplete sorting logic for DO_SUBSCRIPTION_REL
> objects in DOTypeNameCompare(). When multiple subscription–relation
> entries belong to the same subscription, the comparison does not
> establish a complete ordering. In this case, the comparison falls
> through to the generic assertion path. The attached patch fixes this
> by extending the comparison for DO_SUBSCRIPTION_REL objects to include
> deterministic ordering keys. After the subscription name comparison,
> entries are ordered by the referenced table's schema name and then by
> table name.
> 
> This issue has started failing after commit:
> commit 0decd5e89db9f5edb9b27351082f0d74aae7a9b6
> Sort dump objects independent of OIDs, for the 7 holdout object types.
> 
> This can be reproduced by having logical replication setup with
> subscription subscribing to few tables.

That makes sense.  Thanks.  Do you have commands we could add to
src/test/regress/sql/subscription.sql to cover this code?

On Tue, 16 Dec 2025 at 00:00, Noah Misch <noah@leadboat.com> wrote:
>
> On Mon, Dec 15, 2025 at 11:35:35PM +0530, vignesh C wrote:
> > While verifying upgrade of subscriber instance, I noticed pg_dump
> > crash caused by incomplete sorting logic for DO_SUBSCRIPTION_REL
> > objects in DOTypeNameCompare(). When multiple subscription–relation
> > entries belong to the same subscription, the comparison does not
> > establish a complete ordering. In this case, the comparison falls
> > through to the generic assertion path. The attached patch fixes this
> > by extending the comparison for DO_SUBSCRIPTION_REL objects to include
> > deterministic ordering keys. After the subscription name comparison,
> > entries are ordered by the referenced table's schema name and then by
> > table name.
> >
> > This issue has started failing after commit:
> > commit 0decd5e89db9f5edb9b27351082f0d74aae7a9b6
> > Sort dump objects independent of OIDs, for the 7 holdout object types.
> >
> > This can be reproduced by having logical replication setup with
> > subscription subscribing to few tables.
>
> That makes sense.  Thanks.  Do you have commands we could add to
> src/test/regress/sql/subscription.sql to cover this code?

This dumping of subscription relation is specific to upgrading to
preserve the subscription relation. So I felt we will not be able to
add tests to subscription.sql, instead how about adding one more table
to 004_subscription.pl where subscription upgrade tests are verified
like the attached patch.

Regards,
Vignesh