Streaming Replication limitations

Hi,

On Wed, 2011-04-13 at 23:23 +0530, raghu ram wrote:

Is there any limitations to configure streaming replication between
different operating systems i.e solaris 64 bit to RHEL 64 bit.

It won't work.

Regards,

--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

On Wed, Apr 13, 2011 at 11:23:24PM +0530, raghu ram wrote:

Hi,

Is there any limitations to configure streaming replication between
different operating systems i.e solaris 64 bit to RHEL 64 bit.

I personally wouldn't be willing to use anything except identical
binaries for the back end, and those two platforms are binary
incompatible. The manual actually warns about this.

A

--
Andrew Sullivan
ajs@crankycanuck.ca

Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <devrim@gunduz.org> writes:

On Wed, 2011-04-13 at 23:23 +0530, raghu ram wrote:

Is there any limitations to configure streaming replication between
different operating systems i.e solaris 64 bit to RHEL 64 bit.

It won't work.

As long as it's the same machine architecture, it probably will ...
but if "solaris" here really means "sparc" then I agree.

Short answer is to test the case you have in mind and see.

regards, tom lane

since your onine logs are in different endian notation. I do not see how
it would work. Sony may be an option in this case.
Andrew Shved

From:
Tom Lane <tgl@sss.pgh.pa.us>
To:
Devrim GÜNDÜZ <devrim@gunduz.org>
Cc:
raghu ram <raghuchennuru@gmail.com>, pgsql-admin@postgresql.org,
pgsql-general@postgresql.org
Date:
04/13/2011 02:14 PM
Subject:
Re: [ADMIN] Streaming Replication limitations
Sent by:
pgsql-admin-owner@postgresql.org

Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <devrim@gunduz.org> writes:

On Wed, 2011-04-13 at 23:23 +0530, raghu ram wrote:

Is there any limitations to configure streaming replication between
different operating systems i.e solaris 64 bit to RHEL 64 bit.

It won't work.

As long as it's the same machine architecture, it probably will ...
but if "solaris" here really means "sparc" then I agree.

Short answer is to test the case you have in mind and see.

regards, tom lane

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

just hit me what if we use pg_standby and convert archive logs from one
notation to the other. and after apply them to our standby. can this
work?
Andrew Shved
DBA, Symcor Inc, Delivery Support Services
( Phone: 905-273-1433
( BlackBerry: 416-803-2675
* Email: ashved@symcor.com

From:
Tom Lane <tgl@sss.pgh.pa.us>
To:
Devrim GÜNDÜZ <devrim@gunduz.org>
Cc:
raghu ram <raghuchennuru@gmail.com>, pgsql-admin@postgresql.org,
pgsql-general@postgresql.org
Date:
04/13/2011 02:14 PM
Subject:
Re: [ADMIN] Streaming Replication limitations
Sent by:
pgsql-admin-owner@postgresql.org

Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <devrim@gunduz.org> writes:

On Wed, 2011-04-13 at 23:23 +0530, raghu ram wrote:

Is there any limitations to configure streaming replication between
different operating systems i.e solaris 64 bit to RHEL 64 bit.

It won't work.

As long as it's the same machine architecture, it probably will ...
but if "solaris" here really means "sparc" then I agree.

Short answer is to test the case you have in mind and see.

regards, tom lane

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

2011/4/13 Tom Lane <tgl@sss.pgh.pa.us>:

Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <devrim@gunduz.org> writes:

On Wed, 2011-04-13 at 23:23 +0530, raghu ram wrote:

Is there any limitations to configure streaming replication between
different operating systems i.e solaris 64 bit to RHEL 64 bit.

It won't work.

As long as it's the same machine architecture, it probably will ...
but if "solaris" here really means "sparc" then I agree.

Short answer is to test the case you have in mind and see.

That's the long answer, not least because the absence of a failure in
a test is not conclusive proof that it won't fail at some point in the
future while in production.

The short answer is "don't do it".

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Simon Riggs <simon@2ndQuadrant.com> writes:

2011/4/13 Tom Lane <tgl@sss.pgh.pa.us>:

Short answer is to test the case you have in mind and see.

That's the long answer, not least because the absence of a failure in
a test is not conclusive proof that it won't fail at some point in the
future while in production.

Not really. Every known source of incompatibility (endianness,
alignment, float format, etc) is checked at postmaster startup via
entries in pg_control. If you get the slave postmaster to start at all,
it will probably work, though certainly more extensive testing than that
would be advisable.

The short answer is "don't do it".

DBAs are paid to be incredibly paranoid, and from that mindset this
answer makes sense. But there's a big difference between "it won't work"
and "I'm afraid to risk my paycheck on this because there might possibly
be some problem that no one knows about yet". Let's be perfectly clear
that this is a question of the second case not the first.

regards, tom lane

On Wed, 2011-04-13 at 14:42 -0400, Tom Lane wrote:

Simon Riggs <simon@2ndQuadrant.com> writes:

2011/4/13 Tom Lane <tgl@sss.pgh.pa.us>:

Short answer is to test the case you have in mind and see.

That's the long answer, not least because the absence of a failure in
a test is not conclusive proof that it won't fail at some point in the
future while in production.

Not really. Every known source of incompatibility (endianness,
alignment, float format, etc) is checked at postmaster startup via
entries in pg_control.

I seem to remember that Mac and Linux have a different notion of what
en_US collation means (I couldn't find any standard anywhere to say that
one was right and the other was wrong). So, that risks index corruption.

Regards,
Jeff Davis