Re: GNU/Hurd portability patches - Mailing list pgsql-hackers
From | Alexander Lakhin |
---|---|
Subject | Re: GNU/Hurd portability patches |
Date | |
Msg-id | a1d9eab8-7063-4eb1-a922-f54923029c52@gmail.com Whole thread Raw |
In response to | Re: GNU/Hurd portability patches (Michael Banck <mbanck@gmx.net>) |
Responses |
Re: GNU/Hurd portability patches
|
List | pgsql-hackers |
24.09.2025 18:52, Michael Banck wrote:
On Wed, Sep 24, 2025 at 10:28:46AM -0400, Tom Lane wrote:It seems plausible that the execution time of the stats test's function-under-test is so short that it sometimes doesn't register as more than zero on a machine with poor clock resolution. It looks like that test only calls the test function once or twice before checking that it's accumulated some runtime, and the test function is nothing more than CREATE FUNCTION test_stat_func() RETURNS VOID LANGUAGE plpgsql AS $$BEGIN END;$$; I'd call this a bug in that test TBH. It'd be saner to make the function do something like pg_sleep for 1ms.I did that in the attached, so far my Hurd VM ran the stats test more than 1000 times without a failure with it. I have the loop running till 10000, I'll report back tomorrow.
If the stats test could be fixed this way, I wonder how to deal with
regress/subscription.sql. When running:
TESTS="$(printf "subscription %.0s" `seq 1000`)" make -s check-tests
on the same Hurd VM, I'm observing:
...
ok 986 - subscription 53 ms
not ok 987 - subscription 53 ms
ok 988 - subscription 53 ms
...
# 4 of 1000 tests failed.
# The differences that caused some tests to fail can be viewed in the file "/home/demo/postgresql/src/test/regress/regression.diffs".
$ cat "/home/demo/postgresql/src/test/regress/regression.diffs"
--- /home/demo/postgresql/src/test/regress/expected/subscription.out 2025-09-24 19:49:53.000000000 +0100
+++ /home/demo/postgresql/src/test/regress/results/subscription.out 2025-09-24 20:06:48.000000000 +0100
@@ -70,7 +70,7 @@
SELECT :'prev_stats_reset' < stats_reset FROM pg_stat_subscription_stats WHERE subname = 'regress_testsub';
?column?
----------
- t
+ f
(1 row)
-- fail - name already exists
diff -U3 /home/demo/postgresql/src/test/regress/expected/subscription.out /home/demo/postgresql/src/test/regress/results/subscription.out
--- /home/demo/postgresql/src/test/regress/expected/subscription.out 2025-09-24 19:49:53.000000000 +0100
+++ /home/demo/postgresql/src/test/regress/results/subscription.out 2025-09-24 20:07:13.000000000 +0100
@@ -70,7 +70,7 @@
SELECT :'prev_stats_reset' < stats_reset FROM pg_stat_subscription_stats WHERE subname = 'regress_testsub';
?column?
----------
- t
+ f
(1 row)
-- fail - name already exists
diff -U3 /home/demo/postgresql/src/test/regress/expected/subscription.out /home/demo/postgresql/src/test/regress/results/subscription.out
--- /home/demo/postgresql/src/test/regress/expected/subscription.out 2025-09-24 19:49:53.000000000 +0100
+++ /home/demo/postgresql/src/test/regress/results/subscription.out 2025-09-24 20:07:28.000000000 +0100
@@ -70,7 +70,7 @@
SELECT :'prev_stats_reset' < stats_reset FROM pg_stat_subscription_stats WHERE subname = 'regress_testsub';
?column?
----------
- t
+ f
(1 row)
-- fail - name already exists
diff -U3 /home/demo/postgresql/src/test/regress/expected/subscription.out /home/demo/postgresql/src/test/regress/results/subscription.out
--- /home/demo/postgresql/src/test/regress/expected/subscription.out 2025-09-24 19:49:53.000000000 +0100
+++ /home/demo/postgresql/src/test/regress/results/subscription.out 2025-09-24 20:07:33.000000000 +0100
@@ -70,7 +70,7 @@
SELECT :'prev_stats_reset' < stats_reset FROM pg_stat_subscription_stats WHERE subname = 'regress_testsub';
?column?
----------
- t
+ f
(1 row)
-- fail - name already exists
Best regards,
Alexander
pgsql-hackers by date: