Re: Fix overflow in DecodeInterval - Mailing list pgsql-hackers

From Joseph Koshakow
Subject Re: Fix overflow in DecodeInterval
Date
Msg-id CAAvxfHdQGiX2xC78y3Y_LTdCiTOWtMXkaLai7s7-mG+=H7qNXA@mail.gmail.com
Whole thread Raw
In response to Re: Fix overflow in DecodeInterval  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fix overflow in DecodeInterval  (Joseph Koshakow <koshy44@gmail.com>)
List pgsql-hackers
On Sun, Feb 20, 2022 at 6:37 PM Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Trap errors from streaming child in pg_basebackup to exit early
Next
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Failed transaction statistics to measure the logical replication progress