Re: Guarding against bugs-of-omission in initdb's setup_depend
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-06-23T04:33:33Z
Lists: pgsql-hackers
Attachments
- check-for-pinning-oversights.patch (text/x-diff) patch
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, Jun 22, 2017 at 2:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> So I'm thinking about adding a regression test case, say in dependency.sql, >> that looks for unpinned objects with OIDs in the hand-assigned range, >> along the lines of this prototype code: > I don't have specific thoughts, but I like the general idea. Here's a more refined proposed patch. After I tightened the pg_depend probes to check refclassid, I started to get complaints about pg_largeobject_metadata. It turns out that large_object.sql creates a large object with OID 3001, which triggered the check (but without the classid test, it'd accidentally been fooled by the existence of a pin entry for pg_proc OID 3001). I'm not sure if it's such a hot idea to make that large object; but on the whole it seems like this needs to be done early in the regression tests so that it's not fooled by whatever random objects might be created later in the tests. I could not quite persuade myself that checking pg_depend belonged in either opr_sanity or type_sanity, so this patch sets up a "misc_sanity" test script to go alongside those two. regards, tom lane
Commits
-
Add testing to detect errors of omission in "pin" dependency creation.
- 8be8510cf89d 10.0 landed