For production: 8.4 or 8.3?

Just looking for experiences of people. Are people already using 8.4
in serious live hosting environments? Thanks.

On Tue, 2009-07-28 at 03:51 +0800, Phoenix Kiula wrote:
> Are people already using 8.4 in serious live hosting environments?

Not yet. There are lots of (important) fixes in CVS which are waiting
for 8.4.1. For production, I'd wait for a while.
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

On Mon, Jul 27, 2009 at 12:51 PM, Phoenix Kiula<phoenix(dot)kiula(at)gmail(dot)com> wrote:
> Just looking for experiences of people. Are people already using 8.4
> in serious live hosting environments? Thanks.
>

Wait..

8.3 is running fine and dandy. Lots of decent sized changes in 8.4
with awaiting fixes. So wait.

And those that have multiple TB's of data, weee another dump and
restore upgrade (pfffft!!!!!)

Tory M Blue wrote on 27.07.2009 22:45:
> And those that have multiple TB's of data, weee another dump and
> restore upgrade (pfffft!!!!!)

Isn't that what pg_migrator is for?

On Mon, Jul 27, 2009 at 4:45 PM, Tory M Blue <tmblue(at)gmail(dot)com> wrote:

>
>
> And those that have multiple TB's of data, weee another dump and
> restore upgrade (pfffft!!!!!)

pg_migrator doesn't need to dump -> restore, it can do an in-place upgrade
of the datafiles for you.

http://archives.postgresql.org/pgsql-committers/2009-06/msg00031.php

--Scott

On Mon, Jul 27, 2009 at 2:48 PM, Thomas Kellerer<spam_eater(at)gmx(dot)net> wrote:
> Tory M Blue wrote on 27.07.2009 22:45:
>>
>> And those that have multiple TB's of data, weee another dump and
>> restore upgrade (pfffft!!!!!)
>
> Isn't that what pg_migrator is for?

I use slony for such things, downtime = zero (ok a few seconds)

On Mon, 2009-07-27 at 22:48 +0200, Thomas Kellerer wrote:
> Tory M Blue wrote on 27.07.2009 22:45:
> > And those that have multiple TB's of data, weee another dump and
> > restore upgrade (pfffft!!!!!)
>
> Isn't that what pg_migrator is for?

It depends, 8.3 and 8.4 are not compatible by default (because of
--integer-datetimes). So, yeah if you are running Debian/Ubuntu but if
you are running Cent/RH with the defaults, pg_migrator isn't going to
work unless you compile Pg from source.

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> It depends, 8.3 and 8.4 are not compatible by default (because of
> --integer-datetimes). So, yeah if you are running Debian/Ubuntu but if
> you are running Cent/RH with the defaults, pg_migrator isn't going to
> work unless you compile Pg from source.

Oh? You think RH/Cent is going to change that default now? Think again.

Of course the real question is whether you trust pg_migrator to not eat
your data. Those who are afraid to trust 8.4.0 will probably not care
to trust pg_migrator for a few versions yet either...

regards, tom lane

On Mon, 2009-07-27 at 19:16 -0400, Tom Lane wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> > It depends, 8.3 and 8.4 are not compatible by default (because of
> > --integer-datetimes). So, yeah if you are running Debian/Ubuntu but if
> > you are running Cent/RH with the defaults, pg_migrator isn't going to
> > work unless you compile Pg from source.
>
> Oh? You think RH/Cent is going to change that default now? Think again.
>

I thought they would get around to changing it now. That is a shame
because RH really can't be used as a production PostgreSQL server (if
date based data is important) unless you recompile or install the
--integer-datetime rpms.

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> On Mon, 2009-07-27 at 19:16 -0400, Tom Lane wrote:
>> Oh? You think RH/Cent is going to change that default now? Think again.

> I thought they would get around to changing it now.

"They" is me, and it's not changing. I'm not blowing a chance at
in-place upgrade to switch the integer-timestamp default.

> because RH really can't be used as a production PostgreSQL server (if
> date based data is important)

I have open bugs about the lack of in-place upgrade. I have never once
heard a customer complain about FP timestamps. So your position is
nonsense.

regards, tom lane

On Mon, 2009-07-27 at 19:44 -0400, Tom Lane wrote:

> > because RH really can't be used as a production PostgreSQL server (if
> > date based data is important)
>
> I have open bugs about the lack of in-place upgrade. I have never once
> heard a customer complain about FP timestamps. So your position is
> nonsense.

Most customers wouldn't even understand the problem. We have systems we
have to custom maintain due to PostgreSQL having ghost data because of
the floating point based timestamp storage.

The problem is very simple. If you run on RH by default you have an
opportunity for data that will disappear in a practical sense. You know
this is true. My response is not nonsense. The data is still there but
it is floating point based and thus, inexact. The where clause that you
expect to retrieve the data, may not.

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

On Mon, 2009-07-27 at 19:44 -0400, Tom Lane wrote:
>
> > I thought they would get around to changing it now.
>
> "They" is me, and it's not changing. I'm not blowing a chance at
> in-place upgrade to switch the integer-timestamp default.

FWIW, to follow PostgreSQL defaults, I changed PGDG rpms to use it by
default. I think this will be the first time that we break compatibility
between RH RPMs and PGDG ones.

It is your playground, but *IMHO* you should not disable a switch that
is on by PostgreSQL's default.

Regards,
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

> FWIW, to follow PostgreSQL defaults, I changed PGDG rpms to use it by
> default. I think this will be the first time that we break compatibility

Ok this discussion became too complex for me. I am a simple guy with a
simple question: will my old data from 8.2.9, which does have some
date/time indexes, will also work in production version of 8.3.7?
Correct?

Thanks.

On Tue, 2009-07-28 at 16:07 +0800, Phoenix Kiula wrote:
>
> Ok this discussion became too complex for me.

:-)

> I am a simple guy with a simple question: will my old data from 8.2.9,
> which does have some date/time indexes, will also work in production
> version of 8.3.7? Correct?

Basically: It will. You will need to dump/restore, that's all. Here is
the relevant part in the docs:

http://www.postgresql.org/docs/current/static/install-upgrading.html

However, please note that there are some changes from 8.2 to 8.3 which
*may* break your application. See here:

http://www.postgresql.org/docs/current/static/release-8-3.html

Regards,
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

2009/7/28 Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>:
> On Mon, 2009-07-27 at 19:44 -0400, Tom Lane wrote:
>>
>> > I thought they would get around to changing it now.
>>
>> "They" is me, and it's not changing.  I'm not blowing a chance at
>> in-place upgrade to switch the integer-timestamp default.
>
> FWIW, to follow PostgreSQL defaults, I changed PGDG rpms to use it by
> default. I think this will be the first time that we break compatibility
> between RH RPMs and PGDG ones.
>
> It is your playground, but *IMHO* you should not disable a switch that
> is on by PostgreSQL's default.

Personally, I'm still doubtful about using pg_migrator on any large
scale 8.3->8.4 migration. I'm definitely hoping it will be something I
feel safer about when going from 8.4->8.5. In which case it makes a
lot of sense to me to bite the bullet now, and switch to integer
timestamps. That way, the 8.4->8.5 migration will be easier.

If it's ever going to be changed, I doubt it's going to get any
*easier* than doing it right now.

--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

I used pg_migrator to migrate my rather large production databases
(couple hundreds GBs). Schemas are easy, as I keep datetimes as
bigints myself (for various reasons) I won't get the float/int
problem.

But I do understand, that keeping dates as floats might cause grief
(unless you create operator that compares timestamps with cast to (0),
etc). But that's another storry.
I wouldn't be afraid to use 8.4. I am using cvs head of postgresql in
testing al the times since 8.1beta , and never had an issue (that
wasn't my own fault).
But goes without saying, every release has bugs, so sooner you test
it, sooner hackers can fix them, if you find one. So my suggestion,
migrate data, do preproduction tests, and stuff. Once you're happy, go
for 8.4

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Personally, I'm still doubtful about using pg_migrator on any large
> scale 8.3->8.4 migration.

Well, I don't trust it much either, so the RPM documentation will
carry a lot of bright red warnings. But how will you be able to
trust it any more for 8.5 if people don't test/use it now?

> If it's ever going to be changed, I doubt it's going to get any
> *easier* than doing it right now.

Sooner or later there will be a non-binary-upgradable release, and
I'll flip the RH/Fedora defaults then. It's bad timing that both of
these things happened in the same release cycle, but I have to play
the hand I've been dealt.

regards, tom lane