Re: pgsql: Rework the pg_statistic_ext catalog
От | Fabien COELHO |
---|---|
Тема | Re: pgsql: Rework the pg_statistic_ext catalog |
Дата | |
Msg-id | alpine.DEB.2.21.1906161933240.21115@lancre обсуждение исходный текст |
Ответ на | Re: pgsql: Rework the pg_statistic_ext catalog (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Rework the pg_statistic_ext catalog
|
Список | pgsql-committers |
Hello Tom, >> I see that Coelho's two bleeding-edge-clang animals are reporting that >> failure too. Normally I'd just ignore those two; And you'd be right. >> they break pretty regularly. Maybe you're using an >> almost-bleeding-edge clang? > > Oh --- I managed to reproduce that failure locally on RHEL6 (nothing > bleeding-edge anywhere), but it went away after make-clean-and-rebuild. > I'm suspicious that the underlying cause was failure to recompile > something that knows the value of CATALOG_VERSION_NO. Hmmm. My animals compile out of the source tree, not sure how this could happen. > This theory is insufficient to explain why Coelho's animals failed, > though. Maybe it would, if you also posit a ccache screwup? But it's > not obvious from their configurations that they're using ccache at all. Indeed, no ccache. The compilers change often (well, once a week), I do not want anything kept across compiler versions. The animals are really testing the compilers as much as they are testing postgres. However, there is an autoconf cache, but I do not see why it would have such an effect. So no clue. -- Fabien.
В списке pgsql-committers по дате отправления: