On Tue, Jun 19, 2012 at 4:14 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> 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.
+1. > The LSNs on pages are still stored in the old format, to avoid changing the > on-disk format and breaking pg_upgrade. The XLogRecPtrs stored the control > file and WAL are changed, however, so an initdb (or at least pg_resetxlog) > is required. Seems fine. > 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 kept the %X/%X representation in error messages etc. I'm quite used to > that output, so reluctant to change it, although it's a bit silly now that > it represents just 64-bit value. Using UINT64_FORMAT would also make the > messages harder to translate. I could go either way on this one, but I have no problem with the way you did it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
