| From: | Joseph Koshakow <koshy44(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Fix overflow in DecodeInterval |
| Date: | 2022-02-21 02:53:56 |
| Message-ID: | CAAvxfHdQGiX2xC78y3Y_LTdCiTOWtMXkaLai7s7-mG+=H7qNXA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Feb 20, 2022 at 6:37 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Couple of quick comments:
Thanks for the comments Tom, I'll work on fixing these and submit a
new patch.
> * The uses of tm2itm make me a bit itchy. Is that sweeping
> upstream-of-there overflow problems under the rug?
I agree, I'm not super happy with that approach. In fact
I'm pretty sure it will cause queries like
SELECT INTERVAL '2147483648:00:00';
to overflow upstream, even though queries like
SELECT INTERVAL '2147483648 hours';
would not. The places tm2itm is being used are
* After DecodeTime
* In interval_to_char.
The more general issue is how to share code with
functions that are doing almost identical things but use
pg_tm instead of the new pg_itm? I'm not really sure what
the best solution is right now but I will think about it. If
anyone has suggestions though, feel free to chime in.
- Joe Koshakow
| From | Date | Subject | |
|---|---|---|---|
| Next Message | osumi.takamichi@fujitsu.com | 2022-02-21 03:45:37 | RE: Failed transaction statistics to measure the logical replication progress |
| Previous Message | Michael Paquier | 2022-02-21 02:03:00 | Re: Trap errors from streaming child in pg_basebackup to exit early |