Re: Use XLOG_CONTROL_FILE macro everywhere?
От | Fujii Masao |
---|---|
Тема | Re: Use XLOG_CONTROL_FILE macro everywhere? |
Дата | |
Msg-id | be2a0cf2-461d-4606-beea-b219c22ab8a6@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Use XLOG_CONTROL_FILE macro everywhere? ("Anton A. Melnikov" <a.melnikov@postgrespro.ru>) |
Ответы |
Re: Use XLOG_CONTROL_FILE macro everywhere?
|
Список | pgsql-hackers |
On 2025/04/05 8:27, Anton A. Melnikov wrote: > Hi! > > On 04.04.2025 19:32, Fujii Masao wrote: >> I'm not sure there's clear consensus yet on the changes in the 0001 and >> 0002 patches, and it might not be worth rushing them in right before >> the feature freeze. So for now, I reviewed and updated only the 0003 patch, >> since there seems to be agreement on that one. >> >> I've attached the updated version. It fixes a typo and replaces >> the remaining hardcoded control file name with the XLOG_CONTROL_FILE macro. > > Thanks! Looks good for me. Thanks for checking! Barring any objections, I'll go ahead and commit the patch. > Maybe extend this to perl tests since there are several hardcoded names too? > The patch attached tries to do this. I had the same thought, i.e., we could use scan_server_header() to pull XLOG_CONTROL_FILE from xlog_internal.h and replace the hardcoded "global/pg_control" in the TAP tests. But for now, that feels like overkill, since the TAP tests already have other hardcoded values like the WAL directory (pg_wal), and we haven't used macros like XLOGDIR there either. Replacing just "global/pg_control" might feel inconsistent, and handling the other cases properly would take more time beyond feature freeze. So I'm thinking it's better to use XLOG_CONTROL_FILE only in C code for now. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: