Re: 9.3 Beta1 status report
| От | Vik Fearing |
|---|---|
| Тема | Re: 9.3 Beta1 status report |
| Дата | |
| Msg-id | 5178FAC1.3070305@dalibo.com обсуждение исходный текст |
| Ответ на | Re: 9.3 Beta1 status report (Heikki Linnakangas <hlinnakangas@vmware.com>) |
| Ответы |
Re: 9.3 Beta1 status report
|
| Список | pgsql-hackers |
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. Thoughts?
В списке pgsql-hackers по дате отправления: