Re: pg_dump crash due to incomplete ordering of DO_SUBSCRIPTION_REL objects
vignesh C <vignesh21@gmail.com>
From: vignesh C <vignesh21@gmail.com>
To: Noah Misch <noah@leadboat.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-16T11:52:36Z
Lists: pgsql-hackers
Attachments
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