Re: pgsql: Remove pg_class.relhaspkey
От | Andres Freund |
---|---|
Тема | Re: pgsql: Remove pg_class.relhaspkey |
Дата | |
Msg-id | 20180314222004.zzxvk55miwbmdafg@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: pgsql: Remove pg_class.relhaspkey (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: