Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Date
Msg-id adthql7euvlmwfe7iaj3t3zl3jyo3oubr32qjfdtgux65qoape@u3wuhp73a77r
Whole thread
In response to Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
List pgsql-hackers
Hi,

On 2026-04-12 14:20:31 -0400, Tom Lane wrote:
> Lukas Fittl <lukas@fittl.com> writes:
> > FWIW, for archive's sake, drongo is green again now, thanks to commit
> > 7fc36c5db550 (Avoid CPUID 0x15/0x16 for Hypervisor TSC frequency).
>
> drongo may be happy, but Coverity is not:
>
> 166         uint64        loop_count;
> 167
> 168         loop_count = test_timing(test_duration, TIMING_CLOCK_SOURCE_SYSTEM, false);
> >>>     CID 1691465:         Incorrect expression  (DIVIDE_BY_ZERO)
> >>>     In function call "output", division by expression "loop_count" which may be zero has undefined behavior.
> 169         output(loop_count);
>
> AFAICS it's correct to complain.  test_timing() visibly can return zero,
> but of the three places where test_timing() is followed by output()
> only one has a defense against that.

I think it should be unreachable as-is (but we should fix it anyway): If the
system clock source doesn't work, we have much bigger issues. If rdtscp works,
rdtsc should better work as well...

Maybe it's enough to add an Assert() to clarify this?  But I guess just
printing a message in that unreachable case would also work.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Next
From: Lukas Fittl
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?