Re: Should we automatically run duplicate_oids? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Should we automatically run duplicate_oids?
Date
Msg-id 20130802050045.GB4174@momjian.us
Whole thread Raw
In response to Should we automatically run duplicate_oids?  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Should we automatically run duplicate_oids?  (Atri Sharma <atri.jiit@gmail.com>)
List pgsql-hackers
On Mon, Jul  8, 2013 at 06:25:44PM -0700, Peter Geoghegan wrote:
> When rebasing a patch that I'm working on, I occasionally forget to
> update the oid of any pg_proc.h entries I may have created. Of course
> this isn't a real problem; when I go to initdb, I immediately
> recognize what has happened. All the same, it seems like there is a
> case to be made for having this run automatically at build time, and
> having the build fail on the basis of there being a duplicate - this
> is something that fails reliably, but only when someone has added
> another pg_proc.h entry, and only when that other person happened to
> choose an oid in a range of free-in-git-tip oids that I myself
> fancied.
>
> Sure, I ought to remember to check this anyway, but it seems
> preferable to make this process more mechanical. I can point to commit
> 55c1687a as a kind of precedent, where the process of running
> check_keywords.pl was made to run automatically any time gram.c is
> rebuilt. Granted, that's a more subtle problem than the one I'm
> proposing to solve, but I still see this as a modest improvement.

FYI, attached is the pgtest script I always run before I do a commit;
it also calls src/tools/pgtest.  It has saved me from erroneous commits
many times.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Regarding BGworkers
Next
From: Craig Ringer
Date:
Subject: HeapTupleSatisfiesDirty fails to test HEAP_XMAX_IS_LOCKED_ONLY for TransactionIdIsInProgress(...)