pg_dump: sortDumpableObjectsByTypeName() doesn't always do that

From: Jacob Champion <pchampion(at)pivotal(dot)io>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: pg_dump: sortDumpableObjectsByTypeName() doesn't always do that
Date: 2018-08-06 19:02:14
Message-ID: CABAq_6Hw+V-Kj7PNfD5tgOaWT_-qaYkc+SRmJkPLeUjYXLdxwQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
pg-dump-sort.patch application/octet-stream 927 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-08-06 19:13:06 Re: pg_dump: sortDumpableObjectsByTypeName() doesn't always do that
Previous Message Tomas Vondra 2018-08-06 18:47:50 Re: Standby trying "restore_command" before local WAL