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