Avoid core dump in pgstat_read_statsfile()
От | Bertrand Drouvot |
---|---|
Тема | Avoid core dump in pgstat_read_statsfile() |
Дата | |
Msg-id | aAieZAvM+K1d89R2@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст |
Ответы |
Re: Avoid core dump in pgstat_read_statsfile()
|
Список | pgsql-hackers |
Hi hackers, please find attached a patch to $SUBJECT. Indeed one could generate a core dump similar to: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000000000a7a7a7 in pgstat_init_entry (kind=129, shhashent=0x7a55845cfd98) at pgstat_shmem.c:314 314 chunk = dsa_allocate0(pgStatLocal.dsa, pgstat_get_kind_info(kind)->shared_size); (gdb) bt #0 0x0000000000a7a7a7 in pgstat_init_entry (kind=129, shhashent=0x7a55845cfd98) at pgstat_shmem.c:314 #1 0x0000000000a72935 in pgstat_read_statsfile () at pgstat.c:1982 #2 0x0000000000a700a8 in pgstat_restore_stats () at pgstat.c:507 by: 1. creating a custom stat kind (non fixed_amount and write_to_file enabled) 2. generate stats 3. stop the engine 4. change the custom PGSTAT_KIND id linked to 1., compile and install 5. re-start the engine I think that a check on pgstat_get_kind_info() is missing for this scenario, the patch adds it. Such a check already exists for PGSTAT_FILE_ENTRY_FIXED and for stats entry identified by name on disk, but not for PGSTAT_FILE_ENTRY_HASH. The v18 existing checks mentioned above as well as the new check were missing in pre-18 but I don't think it's worth a back-patch as the issue is unlikely to occur without custom stats. Adding a v18 open item then. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: