Thread: 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
Attachment
On Mon, Jul 27, 2009 at 12:51 PM, Phoenix Kiula<phoenix.kiula@gmail.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@gmail.com> wrote:
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
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@gmx.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@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
"Joshua D. Drake" <jd@commandprompt.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@commandprompt.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@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
"Joshua D. Drake" <jd@commandprompt.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@jabber.postgresql.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
Attachment
> 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
Attachment
2009/7/28 Devrim GÜNDÜZ <devrim@gunduz.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@hagander.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