From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | John Naylor <jcnaylor(at)gmail(dot)com> |
Cc: | Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>, andreas(at)proxel(dot)se, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, David Fetter <david(at)fetter(dot)org> |
Subject: | Re: unused_oids script is broken with bsd sed |
Date: | 2018-04-25 20:08:03 |
Message-ID: | 19973.1524686883@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
John Naylor <jcnaylor(at)gmail(dot)com> writes:
> Just after you posted, I sent a patch that tweaks the API of
> Catalog.pm for toast and index oids. If you use that API in your
> patch, you can get rid of the extra bookkeeping you added for those
> oids.
I've adjusted these two patches to play together, and pushed them.
> The original scripts skipped the relation and rowtype oids for
> bootstrap catalogs. You've replaced that with two data-level tests for
> pg_class plus pg_type composite types. I think the original test was a
> bit cleaner in this regard.
Yeah, I thought so too. Changed.
> For those following along, these scripts still assume we're in the
> catalog directory. I can hack on that part tomorrow if no one else
> has.
I didn't touch this point.
I notice that duplicate_oids is now a good factor of 10 slower than it was
before (~0.04 sec to ~0.4 sec, on my machine). While this doesn't seem
like a problem for manual use, it seems annoying as part of the standard
build process, especially on slower buildfarm critters. I think we should
do what you said upthread and teach genbki.pl to complain about duplicate
oids, so that we can remove duplicate_oids from the build process.
I went ahead and pushed things as-is so we can confirm that duplicate_oids
has no portability issues that the buildfarm could find. But let's try
to get the build process change in place after a day or so.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2018-04-25 20:09:25 | Re: WIP: a way forward on bootstrap data |
Previous Message | Robert Haas | 2018-04-25 20:00:52 | Re: WIP: a way forward on bootstrap data |