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) wi
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 are totally
different in
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 ca
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 agreeing that in the b
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 float-timestamp servers is not
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 switched
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 and we're not
>> going
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? Should we double down on trying to make this
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 see any way that we could fob off
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 t
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, we
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 would be binary comp
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 under-tested
>> code, wherea
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.
>
> > I don't really
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 this is a different na
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 period
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 pg_upgr
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 looked it was also an opt
> "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 passed to configure,
but
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 that pg_config.h.win32 says
> /* Define to
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 since we switched the def
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 variables with the
appropriate
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 for pg_upgrade using
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 fo
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 I
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 "all integer timestamps" protocol specs, or c
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 cut our losses and
> >> change the specs?
>
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 timestamps" protocol specs, or cut our losses and
>>> change the specs?
>
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 doubling down. It's bad enough that we have
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 many
internal details th
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 Munr
33 matches
Mail list logo
