Re: pg_stat_statements: more test coverage
От | Peter Eisentraut |
---|---|
Тема | Re: pg_stat_statements: more test coverage |
Дата | |
Msg-id | cd63d8ec-b250-4b98-8976-00df4166990c@eisentraut.org обсуждение исходный текст |
Ответ на | Re: pg_stat_statements: more test coverage (Julien Rouhaud <rjuju123@gmail.com>) |
Ответы |
Re: pg_stat_statements: more test coverage
Re: pg_stat_statements: more test coverage |
Список | pgsql-hackers |
On 31.12.23 10:26, Julien Rouhaud wrote: > On Sun, Dec 31, 2023 at 2:28 PM Michael Paquier <michael@paquier.xyz> wrote: >> >> On Sat, Dec 30, 2023 at 08:39:47PM +0100, Peter Eisentraut wrote: >>> Ok, I have committed these two patches. >> >> Please note that the buildfarm has turned red, as in: >> https://buildfarm.postgresql.org/cgi-bin/show_stagxe_log.pl?nm=pipit&dt=2023-12-31%2001%3A12%3A22&stg=misc-check >> >> pg_stat_statements's regression.diffs holds more details: >> SELECT query FROM pg_stat_statements WHERE query LIKE '%t001%' OR query LIKE '%t098%' ORDER BY query; >> query >> -------------------- >> - select * from t001 >> select * from t098 >> -(2 rows) >> +(1 row) > > That's surprising. I wanted to see if there was any specific > configuration but I get a 403. I'm wondering if this is only due to > other tests being run concurrently evicting an entry earlier than > planned. These tests are run in a separate instance and serially, so I don't think concurrency is an issue. It looks like the failing configurations are exactly all the big-endian ones: s390x, sparc, powerpc. So it's possible that this is actually a bug? But unless someone can reproduce this locally and debug it, we should probably revert this for now.
В списке pgsql-hackers по дате отправления: