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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: pg_stat_statements: more test coverage  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Luzanov
Дата:
Сообщение: Re: Things I don't like about \du's "Attributes" column
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: libpqsrv_connect_params should call ProcessWalRcvInterrupts