pg_dump: sortDumpableObjectsByTypeName() doesn't always do that
Jacob Champion <pchampion@pivotal.io>
From: Jacob Champion <pchampion@pivotal.io>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-08-06T19:02:14Z
Lists: pgsql-hackers
Attachments
- pg-dump-sort.patch (application/octet-stream) patch
Hi all, We recently ran into an issue in pg_dump that caused the initial sort-by-name pass to return incorrect results. It doesn't seem to affect overall correctness, since the later toposort pass takes care of dependencies, but it does occasionally cause a spurious diff in dump output before and after a pg_upgrade run. The key appears to be in this comment, in pg_dump_sort.c: /* * Sort by namespace. Note that all objects of the same type should * either have or not have a namespace link, so we needn't be fancy about * cases where one link is null and the other not. */ This doesn't appear to be correct anymore. From scanning the code, it looks like the DO_DEFAULT_ACL type can optionally have a NULL namespace. Even if it were correct, we can get to this part of the code with objects of different types, as long as they share the same sort priority (see DO_COLLATION and DO_TRANSFORM). We only ran into this because of a bug in Greenplum that caused two types to share a sort priority where they previously did not. A quick and dirty patch is attached, which simply defines an ordering between NULL and non-NULL namespaces so that quicksort behaves rationally. WDYT? --Jacob
Commits
-
Ensure pg_dump_sort.c sorts null vs non-null namespace consistently.
- f7364300667b 11.0 landed
- f3f6558b5d76 9.5.15 landed
- dc391dacf170 10.6 landed
- abd04e0dd8a5 9.4.20 landed
- 6b6327d938ed 9.6.11 landed
- 5b5ed4756c9b 12.0 landed
- 5abdb33ad053 9.3.25 landed
-
Last-minute updates for release notes.
- e0ee93053998 12.0 cited