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/4FD09B5E020000250004818B@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