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

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