Re: Cleaning up historical portability baggage

From: Michael Banck <mbanck(at)gmx(dot)net>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cleaning up historical portability baggage
Date: 2025-06-10 21:05:11
Message-ID: 68489e08.df0a0220.3c14af.fdc6@mx.google.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Tue, Jun 10, 2025 at 12:59:16PM +0200, Michael Banck wrote:
> On Tue, Jun 10, 2025 at 09:05:03AM +1200, Thomas Munro wrote:
> > https://savannah.gnu.org/task/?7050
>
> 3. make check nowadays succeeds the subscription test that it failed in
> the log mentioned in the above task, but it still fails the stats test:

I take that back, the subscription test is flakey, but less so than the
stats test as it only has one of those stats_reset comparisons, compared
to several for stats. So I am seeing failures there only every few test
runs.

The reason those tests fail is that the Debian 12 era [1] GNU Mach I am
currently using has 10ms timer resolution, so some of those stats_reset
calls in quick succession do not lead to different timestamps and the
checks fail.

There are several "SELECT pg_sleep(0.1);" calls in stats.sql already, so
I wonder whether a few more would be acceptable, or at least using
pg_sleep(0.01)? Using the attached, I no longer see regression failures,
even after running it for 10+ times.

The good news is maybe two-fold:

1. GNU Mach recently got better timer resolution and the version in
Debian unstable got that backported [2], so going forward this should
not be a problem anymore. I'll try upgrading my VM and see whether that
helps without the patch.

2. The fact that nobody else complained about those new(er) timestamp-
comparison additions appears to imply that there are no 100ms resolution
machines we support anymore. So did we consider switching those
pg_sleep(0.1) calls in stats.sql to pg_sleep(0.01) to save a bit of
time?

Michael

[1] As hurd-i386 is not a release architecture, there is no Debian 12
release for it. But the Debian GNU/Hurd porters made their own release
based on a snapshot of the hurd-i386 archive at time of the bookworm
release.
[2] https://salsa.debian.org/hurd-team/gnumach/-/blob/master/debian/patches/git-hpet?ref_type=heads

Attachment Content-Type Size
0001-Stabilize-stats_reset-based-tests-for-low-resolution.patch text/x-diff 5.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Banck 2025-06-10 21:09:31 Re: Safeguards against incorrect fd flags for fsync()
Previous Message Masahiko Sawada 2025-06-10 21:00:55 Re: POC: enable logical decoding when wal_level = 'replica' without a server restart