Re: GNU/Hurd portability patches
От | Michael Banck |
---|---|
Тема | Re: GNU/Hurd portability patches |
Дата | |
Msg-id | 68d4dca4.df0a0220.1d3d69.3f28@mx.google.com обсуждение исходный текст |
Ответ на | Re: GNU/Hurd portability patches (Alexander Lakhin <exclusion@gmail.com>) |
Список | pgsql-hackers |
Hi, On Thu, Sep 25, 2025 at 08:00:00AM +0300, Alexander Lakhin wrote: > 25.09.2025 00:22, Michael Banck wrote: > > I ran that five times now without a problem, both with and without the > > Mach patch I mentioned earlier, and on 32 and 64 bit. Not sure what is > > going on here. > > Maybe you're running it against REL_15_STABLE, where this test case is > absent... (I tested that on REL_18_STABLE.) I don't know what can prevent > the test case from failing if the underlying defect is still here. No, I ran it on HEAD an REL_18_STABLE looks similar. > There is also contrib/pg_stat_statements/entry_timestamp, which fails for > me when running in a loop: > for i in `seq 100`; do echo "ITERATION $i"; NO_TEMP_INSTALL=1 make -s check -C contrib/pg_stat_statements || break; done The two test cases above failed frequently for me before I switched to HPET timers, but on amd64 (which you are running as I understand), those are activated by default, so this should not be a problem. What does pg_test_timing from HEAD report as "Average loop time including overhead" for your VM? Michael
В списке pgsql-hackers по дате отправления: