On Tue, Feb 7, 2012 at 17:29, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On 07.02.2012 16:55, Tom Lane wrote: >> >> (The integer vs float TimestampTz issue is a kind of portability >> problem, but we've already bought into the assumption that sender and >> receiver must be built with the same choice, no?) > > > Hmm, true. In hindsight, I think that was a bad choice, but it's a bit late > to change that. pg_basebackup doesn't otherwise care about the integer/float > timestamps, but it does send a timestamp back to the server. You won't be > able to actually start up the database if the config options don't match, > but I think it would be good if pg_basebackup still worked across platforms > and versions. For example, you might have a central backup server that calls > pg_basebackup on several database servers, running on different platforms. > > In 9.0, the only field in the protocol that depends on timestamp format is > WalDataMessageHeader->sendTime. That goes from server to client, and > pg_basebackup/pg_receivexlog don't care about that. In 9.1 we introduced > StandbyReplyMessage->sendTime, which is sent from client to server, but > looking at the code it looks like the server doesn't use it for anything. In > 9.2, we added WalSndrMessage->sendTime, which is used by a standby server to > calculate how far behind the standby is. > > I'm tempted to just change all of those TimestampTz fields to something > that's independent of integer/float timestamp setting, in 9.2. At a quick > glance, it seems that it wouldn't break anything.
In general, I think that would work. Since we can't replicate across versions anyway. Will it break using pg_basebackup 9.2 on a 9.1 server, though? that would also be very useful in the scenario of the central server... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
