Re: unused_oids script is broken with bsd sed - Mailing list pgsql-hackers

From Tom Lane
Subject Re: unused_oids script is broken with bsd sed
Date
Msg-id 19973.1524686883@sss.pgh.pa.us
Whole thread Raw
In response to Re: unused_oids script is broken with bsd sed  (John Naylor <jcnaylor@gmail.com>)
Responses Re: unused_oids script is broken with bsd sed
List pgsql-hackers
John Naylor <jcnaylor@gmail.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: WIP: a way forward on bootstrap data
Next
From: Mark Dilger
Date:
Subject: Re: WIP: a way forward on bootstrap data