Re: [HACKERS] Replication vs. float timestamps is a disaster
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Replication vs. float timestamps is a disaster |
Дата | |
Msg-id | 20170222135634.gnlqu6by2xbpvwii@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Replication vs. float timestamps is a disaster (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Replication vs. float timestamps is a disaster
(Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: [HACKERS] Replication vs. float timestamps is a disaster (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2017-02-22 08:43:28 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2017-02-22 00:10:35 -0600, Jim Nasby wrote: > >> I wounder if a separate "floatstamp" data type might fit the bill there. It > >> might not be completely seamless, but it would be binary compatible. > > > I don't really see what'd that solve. > > Seems to me this is a different name for what I already tried in > <27694.1487456324@sss.pgh.pa.us>. It would be much better than doing > nothing, IMO, but it would still leave lots of opportunities for mistakes. It sounded more like Jim suggested a full blown SQL type, given that he replied to my concern about the possible need for a deprecation period due to pg_upgrade concerns. To be useful for that, we'd need a good chunk of magic, so all existing uses of timestamp[tz] are replaced with floattimestamp[tz], duplicate some code, add implicit casts, and accept that composites/arrays won't be fixed. That sounds like a fair amount of work to me, and we'd still have no way to remove the code without causing pain. > 1. Just patch the already-identified float-vs-int-timestamp bugs in as > localized a fashion as possible, and hope that there aren't any more and > that we never introduce any more. I find this hope foolish :-(, > especially in view of the fact that what started this discussion is a > newly-introduced bug of this ilk. Well, the newly introduced bug was just a copy of the existing code. I'm far less negative about this than you - we're not dealing with a whole lot of code here. I don't get why it'd be foolish to verify the limited amount of code dealing with replication protocol timestamp. > 4. Give up on float timestamps altogether. > > While I'm generally not one to vote for dropping backwards-compatibility > features, I have to say that I find #4 the most attractive of these > options. It would result in getting rid of boatloads of under-tested > code, whereas #2 would really just add more, and #3 at best maintains > the status quo complexity-wise. > (To be concrete, I'm suggesting dropping --disable-integer-datetimes > in HEAD, and just agreeing that in the back branches, use of replication > protocol with float-timestamp servers is not supported and we're not > going to bother looking for related bugs there. Given the lack of field > complaints, I do not believe anyone cares.) I think we should just fix it in the back branches, and drop the float timestamp code in 10 or 11. I.e. 1) and then 4). Greetings, Andres Freund
В списке pgsql-hackers по дате отправления:
Следующее
От: Stephen FrostДата:
Сообщение: Re: [HACKERS] Replication vs. float timestamps is a disaster