| От | Bossart, Nathan |
|---|---|
| Тема | Re: Strange path from pgarch_readyXlog() |
| Дата | |
| Msg-id | 0678CBBA-8209-41E9-9A53-ACE63D71CE10@amazon.com обсуждение исходный текст |
| Ответ на | Re: Strange path from pgarch_readyXlog() (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Strange path from pgarch_readyXlog()
|
| Список | pgsql-hackers |
On 12/29/21, 1:04 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: > "Bossart, Nathan" <bossartn@amazon.com> writes: >> I bet this was a simple mistake in beb4e9b. > >> -static char arch_filenames[NUM_FILES_PER_DIRECTORY_SCAN][MAX_XFN_CHARS]; >> +static char arch_filenames[NUM_FILES_PER_DIRECTORY_SCAN][MAX_XFN_CHARS + 1]; > > Hm, yeah, that looks like a pretty obvious bug. > > While we're here, I wonder if we ought to get rid of the static-ness of > these arrays. I realize that they're only eating a few kB, but they're > doing so in every postgres process, when they'll only be used in the > archiver. This crossed my mind, too. I also think one of the arrays can be eliminated in favor of just using the heap (after rebuilding with a reversed comparator). Here is a minimally-tested patch that demonstrates what I'm thinking. Nathan
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера