Re: pg_waldump vs. all-zeros WAL files; server creation of such files

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pg_waldump vs. all-zeros WAL files; server creation of such files
Дата
Msg-id ZNmFYUm2eRVtofyd@paquier.xyz
обсуждение исходный текст
Ответ на pg_waldump vs. all-zeros WAL files; server creation of such files  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On Sat, Aug 12, 2023 at 08:15:31PM -0700, Noah Misch wrote:
> The attached 010_zero.pl, when run as part of the pg_waldump test suite, fails
> at today's master (c36b636) and v15 (1bc19df).  It passes at v14 (5a32af3).
> Command "pg_waldump --start 0/01000000 --end 0/01000100" fails as follows:
>
>   pg_waldump: error: WAL segment size must be a power of two between
>   1 MB and 1 GB, but the WAL file "000000010000000000000002" header
>   specifies 0 bytes

So this depends on the ordering of the entries retrieved by readdir()
as much as the segments produced by the backend.

> Where it fails, the server has created an all-zeros WAL file under that name.
> Where it succeeds, that file doesn't exist at all.  Two decisions to make:
>
> - Should a clean server shutdown ever leave an all-zeros WAL file?  I think
>   yes, it's okay to let that happen.

It doesn't hurt to leave that around.  On the contrary, it makes any
follow-up startup cheaper the bigger the segment size.

> - Should "pg_waldump --start $X --end $Y" open files not needed for the
>   requested range?  I think no.

So this is a case where identify_target_directory() is called with a
fname of NULL.  Agreed that search_directory could be smarter with the
files it should scan, especially if we have start and/or end LSNs at
hand to filter out what we'd like to be in the data folder.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Naive handling of inequalities by nbtree initial positioning code
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [PoC] pg_upgrade: allow to upgrade publisher node