On 2018-03-14 18:09:07 -0400, Stephen Frost wrote:
> Greetings,
>
> * Andres Freund (andres@anarazel.de) wrote:
> > On 2018-03-14 19:35:40 +0000, Peter Eisentraut wrote:
> > > Remove pg_class.relhaspkey
> > >
> > > It is not used for anything internally, and it cannot be relied on for
> > > external uses, so it can just be removed. To correct recommended way to
> > > check for a primary key is in pg_index.
> > >
> > > Discussion: https://www.postgresql.org/message-id/flat/b1a24c6c-6913-f89c-674e-0704f0ed69db@2ndquadrant.com
> >
> > I'm not clear on the mechanics, and the animal doesn't show the critical
> > log. But this might have caused the issue, being the only commit between
> > runs:
> >
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2018-03-14%2019%3A37%3A20
> >
> > Andrew, any chance you could modify the module to capture
> > pg_upgrade_dump_*.log?
>
> I've not quite tracked it down, but I would caution against blaming this
> commit- when doing some parallel regression test runs, I was seeing
> failures also, but they've not been consistent and I was trying to get
> something else done so didn't focus on them, so they may have been
> failures due to my environment, but might also be some kind of race
> condition in an earlier commit (my guess at the moment is actually the
> INOUT arguments for procedures commit...).
>
> I'll try doing some more runs to see if I can reproduce it, but wanted
> to mention it, just to encourage people to consider looking more broadly
> than just this commit if they run into similar issues.
It failed identically twice in a row now, preceded by a significant
number of successful runs:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=crake&br=HEAD
and afaik there's no concurrency during the cross-version test. So
sure, it's possible that something else is to blame, but I'd not bet on
it.
Greetings,
Andres Freund