| 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 16:45:28 |
| Message-ID: | 2820407.1697561128@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> 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.
Whoops, no: for negative starting values we'd need truncate-towards-
minus-infinity division whereas C99 specifies truncate-towards-zero.
However, the attached does pass for me on cfarm111 as well as my
usual dev machine.
Presumably this is a pre-existing bug that also appears in back
branches. But in the interests of science I propose that we
back-patch only the test case and see which machine(s) fail it
before back-patching the code change.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| v1-fix-timetz-modulo-ops.patch | text/x-diff | 2.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2023-10-17 16:45:52 | Re: New WAL record to detect the checkpoint redo location |
| Previous Message | Nathan Bossart | 2023-10-17 16:45:17 | Re: stopgap fix for signal handling during restore_command |