Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id E1C611337BCF for ; Thu, 14 Apr 2011 20:31:42 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 13896-02-6; Thu, 14 Apr 2011 23:31:30 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-px0-f174.google.com (mail-px0-f174.google.com [209.85.212.174]) by mail.postgresql.org (Postfix) with ESMTP id 6861F1337B93; Thu, 14 Apr 2011 20:30:50 -0300 (ADT) Received: by pxi15 with SMTP id 15so1796971pxi.33 for ; Thu, 14 Apr 2011 16:30:50 -0700 (PDT) Received: by 10.68.10.137 with SMTP id i9mr924978pbb.427.1302823850747; Thu, 14 Apr 2011 16:30:50 -0700 (PDT) Received: from [10.10.3.129] (71-6-94-66.static-ip.telepacific.net [71.6.94.66]) by mx.google.com with ESMTPS id k2sm40113pbj.47.2011.04.14.16.30.47 (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 16:30:48 -0700 (PDT) Subject: Re: [GENERAL] Streaming Replication limitations From: Jeff Davis To: Tom Lane Cc: Simon Riggs , Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= , raghu ram , pgsql-admin , pgsql-general In-Reply-To: <10017.1302720177@sss.pgh.pa.us> References: <1302717319.8788.4.camel@lenovo01-laptop03.gunduz.org> <9304.1302718017@sss.pgh.pa.us> <10017.1302720177@sss.pgh.pa.us> Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 14 Apr 2011 16:30:46 -0700 Message-ID: <1302823846.7584.2.camel@jdavis-ux.asterdata.local> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=2.419 tagged_above=-10 required=5 tests=BAYES_00=-1.9, FS_REPLICA=3.599, SARE_SPEC_REPLICA=0.72 X-Spam-Level: ** X-Archive-Number: 201104/145 X-Sequence-Number: 37326 On Wed, 2011-04-13 at 14:42 -0400, Tom Lane wrote: > Simon Riggs writes: > > 2011/4/13 Tom Lane : > >> 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