Re: oldest/newestCommitTs output by pg_controldata
Вложения
В списке pgsql-hackers по дате отправления:
| От | Joe Conway |
|---|---|
| Тема | Re: oldest/newestCommitTs output by pg_controldata |
| Дата | |
| Msg-id | 5681912F.1020101@joeconway.com обсуждение исходный текст |
| Ответ на | Re: oldest/newestCommitTs output by pg_controldata (Joe Conway <mail@joeconway.com>) |
| Ответы |
Re: oldest/newestCommitTs output by pg_controldata
|
| Список | pgsql-hackers |
On 12/28/2015 10:35 AM, Joe Conway wrote: > An alternative would be to not have a space at all for those two, e.g. > > "Latest checkpoint's oldestCommitTsXid:%u\n" > "Latest checkpoint's newestCommitTsXid:%u\n" > > That isn't too bad and would leave everything aligned. That seems like the best solution to me. 8<----------------------- ... Latest checkpoint's oldestMultiXid: 1 Latest checkpoint's oldestMulti's DB: 1 Latest checkpoint's oldestCommitTsXid:0 Latest checkpoint's newestCommitTsXid:0 Time of latest checkpoint: Thu 24 Dec 2015 08:55:27 AM PST Fake LSN counter for unlogged rels: 0/1 ... 8<----------------------- Anyone parsing based on fixed length would be ok, and so would anyone splitting on the colon. I retract my earlier suggestion of doing HEAD different from REL9_5_STABLE, at least for the moment. My patch for pg_controldata related functions is going to impact all this anyway, so we might as well not fuss about it now. Any objections to the attached? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера