On Sat, Aug 13, 2022 at 12:08:43PM -0700, Andres Freund wrote:
> On 2017-10-13 11:24:05 -0700, Andres Freund wrote:
> > On 2017-10-13 14:19:22 -0400, Tom Lane wrote:
> > > > So it'd probably better to introduce a FORCE_DISABLE_RESTRICT=yes, set
> > > > at the same place, that's then tested before running the relevant
> > > > configure check?
> > >
> > > +1. I think you don't actually have to skip the configure check,
> > > and there might be some value in letting it carry on normally
> > > (so that "restrict" is set properly). We'd just want it to affect
> > > what pg_restrict gets defined as. Something like
> >
> > > if test "$ac_cv_c_restrict" = "no" -o "x$FORCE_DISABLE_RESTRICT" = "xyes"; then
> > > pg_restrict=""
> > > else
> > > pg_restrict="$ac_cv_c_restrict"
> >
> > Yea, that works. Will make it so.
>
> Any chance you could check if this is still needed? I've a FIXME about it in
> the meson code that I'd like to get rid of :)
I ran hornet against 1c497fa72d, the commit that failed in
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2017-10-12%2022%3A14%3A41.
Similar failure today: "172 of 181 tests failed, 1 of these failures ignored."