On 09/06/17 18:33, Omar Kilani wrote:
> Is there anything people using float datetimes can do that isn't a
> pg_dumpall | pg_restore to do a less painful update?
>
> We have several TB of data still using float datetimes and I'm trying
> to figure out how we can move to 10 (currently on 9.6.x)
Omar Kilani writes:
> Is there anything people using float datetimes can do that isn't a
> pg_dumpall | pg_restore to do a less painful update?
Um, not really. You may be stuck on 9.6 until you can spare the effort
to convert. The physical representations of timestamps
Hi,
I know I'm 7 months late to this, but only just read the beta 4 release notes.
Is there anything people using float datetimes can do that isn't a
pg_dumpall | pg_restore to do a less painful update?
We have several TB of data still using float datetimes and I'm trying
to figure out how we
On 2017-02-27 17:00:23 -0800, Joshua D. Drake wrote:
> On 02/22/2017 02:45 PM, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2017-02-22 08:43:28 -0500, Tom Lane wrote:
> > > > (To be concrete, I'm suggesting dropping --disable-integer-datetimes
> > > > in HEAD, and just
On 02/22/2017 02:45 PM, Tom Lane wrote:
Andres Freund writes:
On 2017-02-22 08:43:28 -0500, Tom Lane wrote:
(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
On Mon, Feb 20, 2017 at 09:07:33AM -0500, Tom Lane wrote:
> The question to be asked is whether there is still anybody out there
> using float timestamps. I'm starting to get dubious about it myself.
> Certainly, no packager that I'm aware of has shipped a float-timestamp
> build since we
Andres Freund writes:
> On 2017-02-22 08:43:28 -0500, Tom Lane wrote:
>> (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
On Mon, Feb 20, 2017 at 11:58:12AM +0100, Petr Jelinek wrote:
> On 20/02/17 08:03, Andres Freund wrote:
> > On 2017-02-19 10:49:29 -0500, Tom Lane wrote:
> >> Robert Haas writes:
> >>> On Sun, Feb 19, 2017 at 3:31 AM, Tom Lane wrote:
> Thoughts?
Andrew Dunstan writes:
> On 02/22/2017 10:21 AM, Jim Nasby wrote:
>> Only in the catalog though, not the datums, right? I would think you
>> could just change the oid in the catalog the same as you would for a
>> table column.
> No, in the datums.
Yeah, I don't
On 02/22/2017 10:21 AM, Jim Nasby wrote:
> On 2/22/17 9:12 AM, Andres Freund wrote:
>>> That would allow an in-place upgrade of
>>> a really large cluster. A user would still need to modify their code
>>> to use
>>> the new type.
>>>
>>> Put another way: add ability for pg_upgrade to change the
On 2/22/17 9:12 AM, Andres Freund wrote:
That would allow an in-place upgrade of
a really large cluster. A user would still need to modify their code to use
the new type.
Put another way: add ability for pg_upgrade to change the type of a field.
There might be other uses for that as well.
Type
On 2017-02-22 09:06:38 -0600, Jim Nasby wrote:
> On 2/22/17 7:56 AM, Andres Freund wrote:
> > 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,
On 2/22/17 7:56 AM, Andres Freund wrote:
On 2017-02-22 08:43:28 -0500, Tom Lane wrote:
Andres Freund 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
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> 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
Tom, all,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> 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
On 2017-02-22 08:43:28 -0500, Tom Lane wrote:
> Andres Freund 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.
>
Andres Freund 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
On 2017-02-22 00:10:35 -0600, Jim Nasby wrote:
> On 2/20/17 5:04 AM, Andres Freund wrote:
> > On 2017-02-20 11:58:12 +0100, Petr Jelinek wrote:
> > > That being said, I did wonder myself if we should just deprecate float
> > > timestamps as well.
> >
> > I think we need a proper deprecation
On 2/20/17 5:04 AM, Andres Freund wrote:
On 2017-02-20 11:58:12 +0100, Petr Jelinek wrote:
That being said, I did wonder myself if we should just deprecate float
timestamps as well.
I think we need a proper deprecation period for that, given that the
conversion away will be painful for
On 2/21/17 4:52 PM, James Cloos wrote:
"TL" == Tom Lane writes:
TL> The question to be asked is whether there is still anybody out there
TL> using float timestamps.
Gentoo's ebuild includes:
$(use_enable !pg_legacytimestamp integer-datetimes) \
FWIW, last time I
> "TL" == Tom Lane writes:
TL> The question to be asked is whether there is still anybody out there
TL> using float timestamps.
Gentoo's ebuild includes:
$(use_enable !pg_legacytimestamp integer-datetimes) \
meaning that by default --enable-integer-datetimes is
Robert Haas writes:
> On Mon, Feb 20, 2017 at 7:37 PM, Tom Lane wrote:
>> The question to be asked is whether there is still anybody out there
>> using float timestamps. I'm starting to get dubious about it myself.
> I'm wondering if it has any effect
On Mon, Feb 20, 2017 at 7:37 PM, Tom Lane wrote:
> The question to be asked is whether there is still anybody out there
> using float timestamps. I'm starting to get dubious about it myself.
> Certainly, no packager that I'm aware of has shipped a float-timestamp
> build
Petr Jelinek writes:
> It's definitely not hard, we already have
> IntegerTimestampToTimestampTz() which does the opposite conversion anyway.
It's not the functions that are hard, it's making sure that you have used
them in the correct places, and declared relevant
Andres Freund writes:
> On 2017-02-20 11:58:12 +0100, Petr Jelinek wrote:
>> That being said, I did wonder myself if we should just deprecate float
>> timestamps as well.
> I think we need a proper deprecation period for that, given that the
> conversion away will be painful
On 20/02/17 12:04, Andres Freund wrote:
> On 2017-02-20 11:58:12 +0100, Petr Jelinek wrote:
>> That being said, I did wonder myself if we should just deprecate float
>> timestamps as well.
>
> I think we need a proper deprecation period for that, given that the
> conversion away will be painful
On 2017-02-20 11:58:12 +0100, Petr Jelinek wrote:
> That being said, I did wonder myself if we should just deprecate float
> timestamps as well.
I think we need a proper deprecation period for that, given that the
conversion away will be painful for pg_upgrade using people with big
clusters. So
On 20/02/17 08:03, Andres Freund wrote:
> On 2017-02-19 10:49:29 -0500, Tom Lane wrote:
>> Robert Haas writes:
>>> On Sun, Feb 19, 2017 at 3:31 AM, Tom Lane wrote:
Thoughts? Should we double down on trying to make this work according
to the
On 2017-02-19 10:49:29 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Sun, Feb 19, 2017 at 3:31 AM, Tom Lane wrote:
> >> Thoughts? Should we double down on trying to make this work according
> >> to the "all integer timestamps" protocol specs, or
On Sun, Feb 19, 2017 at 9:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Feb 19, 2017 at 3:31 AM, Tom Lane wrote:
>>> Thoughts? Should we double down on trying to make this work according
>>> to the "all integer
Robert Haas writes:
> On Sun, Feb 19, 2017 at 3:31 AM, Tom Lane wrote:
>> Thoughts? Should we double down on trying to make this work according
>> to the "all integer timestamps" protocol specs, or cut our losses and
>> change the specs?
> I vote for
On Sun, Feb 19, 2017 at 3:31 AM, Tom Lane wrote:
> Thoughts? Should we double down on trying to make this work according
> to the "all integer timestamps" protocol specs, or cut our losses and
> change the specs?
I vote for doubling down. It's bad enough that we have so
Both the streaming replication and logical replication areas of the code
are, approximately, utterly broken when !HAVE_INT64_TIMESTAMPS. (The fact
that "make check-world" passes anyway is an indictment of the quality of
the regression tests.)
I started poking around in this area after Thomas
33 matches
Mail list logo