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