| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, cary huang <hcary328(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Add support for AT LOCAL |
| Date: | 2023-10-17 15:31:06 |
| Message-ID: | 2726901.1697556666@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Tue, Oct 17, 2023 at 01:40:18AM -0400, Tom Lane wrote:
>> makes the failure go away. Unfortunately, I've not yet found another
>> way to make it go away :-(. My upthread idea of using a local variable
>> instead of result->time is no help, and some other random code
>> alterations didn't change the results either.
> That may be a long shot, but even a modulo?
Yeah, the same thing occurred to me in the shower this morning, and it
does seem to work! We can replace both loops with a %= operator, at
least if we're willing to assume C99 division semantics, which seems
pretty safe in 2023. Your idea of doing a range check to skip the
division in typical cases is a refinement I'd not thought of, but
it seems like a good idea for performance.
(I see that the negative-starting-point case isn't covered in the
current regression tests, so maybe we better add a test for that.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Drouvot, Bertrand | 2023-10-17 15:36:51 | Re: Synchronizing slots from primary to standby |
| Previous Message | Robert Haas | 2023-10-17 15:23:52 | Re: run pgindent on a regular basis / scripted manner |