On 25.04.2013 12:43, Vik Fearing wrote:
On 04/24/2013 06:34 PM, Heikki Linnakangas wrote:
Let me clarify --- changes to our WAL binary format and source code
changes are not really incompatibilities from a user perspective as we
never promise to do our best to minimize such changes --- m eaning
the
fact the WAL format changed is something that would be only in the
source code section and not in the "incompatibilities section" ---
incompatibilities are related to change in user experience or
documented-API changes.
These guidelines makes sense, except I think the change in naming
standard of xlog segments is important to document clearly because,
even
if we have not promised compatibility, people could be relying on it in
scripts. I think it makes sense to waste a couple of lines documenting
this change, even if we expect the number of people to be bitten by it
to be very low.
Right. Kevin mentioned he had a script that knew about the numbering:
http://www.postgresql.org/message-id/4fd09b5e0200002500048...@gw.wicourts.gov.
We also have scripts that know about the missing FF. How slim are the
chances of having pg_xlogdump output the version of the wal file for
9.3? I know we're right on top of the deadline, but that tool and this
change are both new to 9.3. That way our scripts could know if a file is
missing or not.
I talked about this briefly with Andres on IRC and he says a patch to do
this would be trivial.
Seems reasonable. Patches are welcome :-). We're not going to guarantee
that pg_xlogdump works across versions, but printing out the version
that generated the file seems easy enough. If your script has access to
the data directory, you could also easily check PG_VERSION.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
