Re: suppressing useless wakeups in logical/worker.c
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>,
"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2023-01-26T18:54:08Z
Lists: pgsql-hackers
Attachments
- fix-TimestampDifferenceMilliseconds.patch (text/x-diff) patch
I wrote: >>> It'd probably be reasonable to file down that sharp edge by instead >>> specifying that TimestampDifferenceMilliseconds will clamp overflowing >>> differences to LONG_MAX. Maybe there should be a clamp on the underflow >>> side too ... but should it be to LONG_MIN or to zero? After looking closer, I see that TimestampDifferenceMilliseconds already explicitly states that its output is intended for WaitLatch and friends, which makes it perfectly sane for it to clamp the result to [0, INT_MAX] rather than depending on the caller to not pass out-of-range values. I checked existing callers, and found one place in basebackup_copy.c that had not read the memo about TimestampDifferenceMilliseconds never returning a negative value, and another in postmaster.c that had not read the memo about Min() and Max() being macros. There are none that are unhappy about clamping to INT_MAX, and at least one that was already assuming it could just cast the result to int. Hence, I propose the attached. I haven't gone as far as to change the result type from long to int; that seems like a lot of code churn (if we are to update WaitLatch and all callers to match) and it won't really buy anything semantically. regards, tom lane
Commits
-
Improve TimestampDifferenceMilliseconds to cope with overflow sanely.
- 3a28d7808928 16.0 landed
-
Code review for commit 05a7be935.
- 24ff700f6aee 16.0 landed