Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 2C72BB8BE76 for ; Sun, 24 Jun 2012 13:24:52 -0300 (ADT) Received: from exprod7og104.obsmtp.com ([64.18.2.161]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SipcJ-0005wg-4M for pgsql-hackers@postgresql.org; Sun, 24 Jun 2012 16:24:51 +0000 Received: from mail-lb0-f179.google.com ([209.85.217.179]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT+c/RNFiLHYTl+vnxacPPhxF101sm7hK@postini.com; Sun, 24 Jun 2012 09:24:50 PDT Received: by lban1 with SMTP id n1so4801546lba.10 for ; Sun, 24 Jun 2012 09:24:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=YCw49b30QQvzO9Un6QkINkXFPeUGgRvhDh9k6RVp9b0=; b=HTW9PUgYHomoGKsvRmUAPCD2Gz4qOFdTQxuFJ14AV+1aJpkqkokvPFzpCLRQkMD4HH sjlgMTGd/blhxvAoA5g+Pfa0N74mrOxutFHYNRESnW5MaCKQtsXOsypXoqbyWzs4sH+y TzPPBNdQxy77Yc9VwfdmYXaQtO5w7wyd9TO69DL8MDJekbvKqaScwSAWI3BJHnTKvm8J wEUn2O+fD9/DYW9bKSAx3oA4l6aSx/DwrU/HrqTTrLnbZNE3+Br3GXdo3xohtD/0vpsc yhJ0laUxrQUdtixVmuOurcTthEGpnTJDViJjnC41fTjFF1VQwdhBsb8/VtfckuQhGPuE bdbA== Received: by 10.112.54.37 with SMTP id g5mr4388137lbp.104.1340555074582; Sun, 24 Jun 2012 09:24:34 -0700 (PDT) Received: from [192.168.1.104] (dsl-hkibrasgw2-ff6cc300-200.dhcp.inet.fi. [88.195.108.200]) by mx.google.com with ESMTPS id d3sm4303958lbh.3.2012.06.24.09.24.32 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jun 2012 09:24:33 -0700 (PDT) Message-ID: <4FE73F3F.5040105@enterprisedb.com> Date: Sun, 24 Jun 2012 19:24:31 +0300 From: Heikki Linnakangas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Robert Haas CC: Andres Freund , pgsql-hackers@postgresql.org Subject: Re: WAL format changes References: <4FDA5136.6080206@enterprisedb.com> <201206142358.12431.andres@2ndquadrant.com> <4FDF6E8E.4080900@enterprisedb.com> <4FE034D0.5070900@enterprisedb.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkECgqONXvdUhuFn6YZFKpcXmN23XPMrLERzH1czD7GnPttRmTbRoyOkm7oBrvWbZ/eq0D8 X-Pg-Spam-Score: -4.2 (----) X-Archive-Number: 201206/1407 X-Sequence-Number: 210247 Ok, committed all the WAL format changes now. On 19.06.2012 18:57, Robert Haas wrote: >> Should we keep the old representation in the replication protocol messages? >> That would make it simpler to write a client that works with different >> server versions (like pg_receivexlog). Or, while we're at it, perhaps we >> should mandate network-byte order for all the integer and XLogRecPtr fields >> in the replication protocol. That would make it easier to write a client >> that works across different architectures, in>= 9.3. The contents of the >> WAL would of course be architecture-dependent, but it would be nice if >> pg_receivexlog and similar tools could nevertheless be >> architecture-independent. > > I share Andres' question about how we're doing this already. I think > if we're going to break this, I'd rather do it in 9.3 than 5 years > from now. At this point it's just a minor annoyance, but it'll > probably get worse as people write more tools that understand WAL. I didn't touch the replication protocol yet, but I think we should do it some time during 9.3. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com