Message-ID: <4FE0FC36.9080409@enterprisedb.com>
Date: Wed, 20 Jun 2012 01:24:54 +0300
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.4) Gecko/20120510 Icedove/10.0.4
MIME-Version: 1.0
To: Andres Freund <andres@2ndquadrant.com>
CC: pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>
Subject: Re: WAL format changes
References: <4FDA5136.6080206@enterprisedb.com>
	<4FDF6E8E.4080900@enterprisedb.com>
	<4FE034D0.5070900@enterprisedb.com>
	<201206191746.41027.andres@2ndquadrant.com>
In-Reply-To: <201206191746.41027.andres@2ndquadrant.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

On 19.06.2012 18:46, Andres Freund wrote:
> On Tuesday, June 19, 2012 10:14:08 AM Heikki Linnakangas wrote:
>> Well, that was easier than I thought. Attached is a patch to make
>> XLogRecPtr a uint64, on top of my other WAL format patches. I think we
>> should go ahead with this.
> Cool. You plan to merge XLogSegNo with XLogRecPtr in that case? I am not sure
> if having two representations which just have a constant factor inbetween
> really makes sense.

I wasn't planning to, it didn't even occur to me that we might be able 
to get rid of XLogSegNo to be honest. There's places that deal whole 
segments, rather than with specific byte positions in the WAL, so I 
think XLogSegNo makes more sense in that context. Take 
XLogArchiveNotifySeg(), for example. It notifies the archiver that a 
given segment is ready for archiving, so we pass an XLogSegNo to 
identify that segment as an argument. I suppose we could pass an 
XLogRecPtr that points to the beginning of the segment instead, but it 
doesn't really feel like an improvement to me.

>> 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.
> The replication protocol uses pq_sendint for integers which should take care
> of converting to big endian already. I don't think anything but the wal itself
> is otherwise transported in a binary fashion? So I don't think there is any
> such architecture dependency in the protocol currently?

We only use pg_sendint() for the few values exchanged in the handshake 
before we start replicating, but once we begin, we just send structs 
around. For example, in ProcessStandbyReplyMessage():

> static void
> ProcessStandbyReplyMessage(void)
> {
> 	StandbyReplyMessage reply;
>
> 	pq_copymsgbytes(&reply_message, (char *) &reply, sizeof(StandbyReplyMessage));
 > ...

After that, we just the fields in the reply struct like in any other struct.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com