Thread: Are folks running 8.4 in production environments? and 8.4 and slon 1.2?

Any issues, has it baked long enough, is it time for us 8.3 folks to deal with the pain and upgrade?

Anymore updates regarding 8.4 and slon 1.2 as well, since I usually build/upgrade both at the same time.

Thanks
Tory

On Mon, Oct 12, 2009 at 1:06 PM, Tory M Blue <tmblue@gmail.com> wrote:
> Any issues, has it baked long enough, is it time for us 8.3 folks to deal
> with the pain and upgrade?

I am running 8.4.1 for my stats and search databases, and it's working fine.

> Anymore updates regarding 8.4 and slon 1.2 as well, since I usually
> build/upgrade both at the same time.

I don't think 1.2 supports 8.4 just yet, and 2.0.3  or so is still not
stable enough for production (I had major unexplained outages with it)
so for now, no 8.4 with slony.

On Tue, Oct 13, 2009 at 01:03:10AM -0600, Scott Marlowe wrote:
> On Mon, Oct 12, 2009 at 1:06 PM, Tory M Blue <tmblue@gmail.com> wrote:
> > Any issues, has it baked long enough, is it time for us 8.3 folks to deal
> > with the pain and upgrade?
>
> I am running 8.4.1 for my stats and search databases, and it's working fine.
>
> > Anymore updates regarding 8.4 and slon 1.2 as well, since I usually
> > build/upgrade both at the same time.
>
> I don't think 1.2 supports 8.4 just yet, and 2.0.3  or so is still not
> stable enough for production (I had major unexplained outages with it)
> so for now, no 8.4 with slony.
>
slony-1.2.17-rc2 works fine with version 8.4 in my limited testing.
I have not been able to get replication to work reliably with any
current release of slony-2.x. There was a recent comment that the
latest version in CVS has the 2.x bug fixed but I have not had a
chance to try.

Regards,
Ken

Tory M Blue schrieb:

> Any issues, has it baked long enough, is it time for us 8.3 folks to deal
> with the pain and upgrade?

I've upgraded all my databases to 8.4. They pain was not so big, the new
-j Parameter from pg_restore is fantastic. I really like the new
functions around Pl/PGSQL. All is stable and fast.

Greetings from Germany,
Torsten
--
http://www.dddbl.de - ein Datenbank-Layer, der die Arbeit mit 8
verschiedenen Datenbanksystemen abstrahiert,
Queries von Applikationen trennt und automatisch die Query-Ergebnisse
auswerten kann.

Torsten Zühlsdorff wrote:
> Tory M Blue schrieb:
>
>> Any issues, has it baked long enough, is it time for us 8.3 folks to
>> deal
>> with the pain and upgrade?
>
> I've upgraded all my databases to 8.4. They pain was not so big, the
> new -j Parameter from pg_restore is fantastic. I really like the new
> functions around Pl/PGSQL. All is stable and fast.
>
> Greetings from Germany,
> Torsten
I am running all my production work on 8.4 at this point; no problems of
note.

-- Karl

Tory M Blue wrote:

Torsten Zühlsdorff wrote:

>
> I've upgraded all my databases to 8.4. They pain was not so big, the
> new -j Parameter from pg_restore is fantastic. I really like the new
> functions around Pl/PGSQL. All is stable and fast.
>
> Greetings from Germany,
> Torsten

On Sat, Oct 17, 2009 at 8:55 PM, Karl Denninger <karl@denninger.net> wrote:

I am running all my production work on 8.4 at this point; no problems of
note.

-- Karl

Thanks guys, ya running slon , must be replicated so it seems 8.4 is good, but need to wait for the slon+pg to be good..

Also not real pain? A full dump and restore again, can't see that not being painful for a DB of any real size.

Thanks for the response guys.

Und Danke Torsten :)

Tory

I am running Slony on 8.4; it complains on init but I have checked it EXTENSIVELY and it is replicating fine.  I have a distributed forum application that uses Slony as part of the backend architecture and it would choke INSTANTLY if there were problems.

Didn't dump and restore.  This is how I migrated it:

1. Set up 8.4 on the same machine.
2. Use slony to add the 8.4 "instance" as a slave.
3. Wait for sync.
4. Stop client software.
5. Change master to the 8.4 instance.
6. Shut down 8.3 instance, change 8.4 instance to the original port (that 8.3 was running on) and restart.
7. Bring client application back up.
8. Verify all is ok, drop the 8.3 instance from replication.

Total downtime was about 2 minutes for steps 4-8, the long wait was for #3, which has no consequence for the clients.

Note that this requires 2x disk storage + some + enough I/O and CPU bandwidth to get away with the additional replication on the master machine.  If you don't have that you need a second machine you can do this to and then swap the client code to run against when the replication is complete.

-- Karl

On Sat, Oct 17, 2009 at 10:13 PM, Karl Denninger <karl@denninger.net> wrote:
> Tory M Blue wrote:
> > Also not real pain? A full dump and restore again, can't see that not being
> > painful for a DB of any real size.

> I am running Slony on 8.4; it complains on init but I have checked it
> EXTENSIVELY and it is replicating fine.  I have a distributed forum
> application that uses Slony as part of the backend architecture and it would
> choke INSTANTLY if there were problems.
>
> Didn't dump and restore.

Yeah, we haven't done that since pgsql 8.1.  Now on 8.3.  Won't be
doing it for 8.4 either.

We use slony to do it here and we wait until it's proven stable as a
slave before we promote 8.4 / new slony to take over.