From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, YUriy Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: clearing opfuncid vs. parallel query |
Date: | 2015-11-10 04:02:10 |
Message-ID: | 20151110040210.GA1189933@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 22, 2015 at 05:14:29PM -0400, Robert Haas wrote:
> On Thu, Oct 22, 2015 at 5:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >> Despite everybody's best efforts, we mess this up more than is really
> >> desirable. Commit b8fe12a83622b350dc6849f8bb933bd8a86c1424 fixed bugs
> >> in a whole bunch of preceding commits, and I wonder if anybody else
> >> would have found those if Noah hadn't. It's just too easy to miss
> >> these things today. If generating the .c files isn't practical,
> >> another alternative worth exploring would be a tool to cross-check
> >> them against the .h files.
FWIW, such a tool found the bugs I fixed in 53bbc68, b5eccae, b8fe12a. My
script generates {copy,equal,out,read}funcs.c functions from the headers and
diffs each function against its hand-maintained counterpart. I read through
the diff for anything suspicious. (Most functions with deliberate nonstandard
behavior carry a comment about it.)
> > Yeah, I could get on board with that. It doesn't seem terribly hard:
> > just make sure that all fields mentioned in the struct declaration are
> > mentioned in each relevant routine. (Cases where we intentionally skip
> > a field could be handled by adding a no-op macro, eg "COPY_IGNORE(foo);")
> >
> > It would be nice if we could also check that the macro type is sane for
> > the field datatype (eg, not use COPY_SCALAR_FIELD() for a pointer field).
> > But that would probably increase the difficulty very substantially for
> > just a small gain in error detection.
>
> I actually think that's quite an easy mistake to make, so I'd be happy
> if we could catch it. But anything would be better than nothing.
So far, type mismatch defects have been no less common than neglecting a field
entirely.
From | Date | Subject | |
---|---|---|---|
Next Message | Adam Brightwell | 2015-11-10 04:38:57 | Re: bootstrap pg_shseclabel in relcache initialization |
Previous Message | Kouhei Kaigai | 2015-11-10 03:26:09 | CustomScan in a larger structure (RE: CustomScan support on readfuncs.c) |