agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Fix PANIC with track_functions due to concurrent drop of pgstats 5+ messages / 1 participants [nested] [flat]
* pgsql: Fix PANIC with track_functions due to concurrent drop of pgstats @ 2026-06-18 02:50 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 5+ messages in thread From: Michael Paquier @ 2026-06-18 02:50 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix PANIC with track_functions due to concurrent drop of pgstats entries pgstat_drop_entry_internal() generates an ERROR if facing a pgstats entry already marked as dropped. With a workload doing a lot of concurrent CALL and DROP/CREATE PROCEDURE, it could be possible for AtEOXact_PgStat_DroppedStats(), that wants to do transactional drops, to find entries that are already dropped, after a commit record has been written. In this case, ERRORs are upgraded to PANIC, taking down the server. This issue is fixed by making pgstat_drop_entry() optionally more tolerant to concurrent drops, adding to the routine a missing_ok option to make some of its callers more tolerant (spoiler: some of the callers want a strict behavior, like replication slots and backend stats). pgstat_drop_entry_internal() cannot be called anymore for an entry marked as dropped, hence its error is replaced by an assertion. Functions are handled as a special case in core; this problem could also apply to custom stats kinds depending on what an extension does. track_functions is costly when enabled (disabled by default), which is perhaps the main reason why this has not be found yet. A similar version of this patch has been proposed by Sami Imseih on a different thread for a feature in development. This version has tweaked here by me for the sake of fixing this issue. Reported-by: zhanglihui <zlh21343@163.com> Author: Sami Imseih <samimseih@gmail.com> Author: Michael Paquier <michael@paquier.xyz> Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Discussion: https://postgr.es/m/19520-73873648d44793cf@postgresql.org Backpatch-through: 15 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/850b9218c8e4aa7a56f4ec34a542d4a37f9e07eb Modified Files -------------- src/backend/utils/activity/pgstat.c | 2 +- src/backend/utils/activity/pgstat_function.c | 2 +- src/backend/utils/activity/pgstat_replslot.c | 2 +- src/backend/utils/activity/pgstat_shmem.c | 28 +++++++++++++++------- src/backend/utils/activity/pgstat_xact.c | 8 +++---- src/include/utils/pgstat_internal.h | 3 ++- .../test_custom_stats/test_custom_var_stats.c | 2 +- 7 files changed, 29 insertions(+), 18 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix PANIC with track_functions due to concurrent drop of pgstats @ 2026-06-18 02:50 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 5+ messages in thread From: Michael Paquier @ 2026-06-18 02:50 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix PANIC with track_functions due to concurrent drop of pgstats entries pgstat_drop_entry_internal() generates an ERROR if facing a pgstats entry already marked as dropped. With a workload doing a lot of concurrent CALL and DROP/CREATE PROCEDURE, it could be possible for AtEOXact_PgStat_DroppedStats(), that wants to do transactional drops, to find entries that are already dropped, after a commit record has been written. In this case, ERRORs are upgraded to PANIC, taking down the server. This issue is fixed by making pgstat_drop_entry() optionally more tolerant to concurrent drops, adding to the routine a missing_ok option to make some of its callers more tolerant (spoiler: some of the callers want a strict behavior, like replication slots and backend stats). pgstat_drop_entry_internal() cannot be called anymore for an entry marked as dropped, hence its error is replaced by an assertion. Functions are handled as a special case in core; this problem could also apply to custom stats kinds depending on what an extension does. track_functions is costly when enabled (disabled by default), which is perhaps the main reason why this has not be found yet. A similar version of this patch has been proposed by Sami Imseih on a different thread for a feature in development. This version has tweaked here by me for the sake of fixing this issue. Reported-by: zhanglihui <zlh21343@163.com> Author: Sami Imseih <samimseih@gmail.com> Author: Michael Paquier <michael@paquier.xyz> Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Discussion: https://postgr.es/m/19520-73873648d44793cf@postgresql.org Backpatch-through: 15 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5cc59834b860ed48d710c1baa9c50c66540c64d0 Modified Files -------------- src/backend/utils/activity/pgstat.c | 2 +- src/backend/utils/activity/pgstat_function.c | 2 +- src/backend/utils/activity/pgstat_replslot.c | 2 +- src/backend/utils/activity/pgstat_shmem.c | 28 +++++++++++++++------- src/backend/utils/activity/pgstat_xact.c | 8 +++---- src/include/utils/pgstat_internal.h | 3 ++- .../modules/injection_points/injection_stats.c | 2 +- 7 files changed, 29 insertions(+), 18 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix PANIC with track_functions due to concurrent drop of pgstats @ 2026-06-18 02:50 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 5+ messages in thread From: Michael Paquier @ 2026-06-18 02:50 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix PANIC with track_functions due to concurrent drop of pgstats entries pgstat_drop_entry_internal() generates an ERROR if facing a pgstats entry already marked as dropped. With a workload doing a lot of concurrent CALL and DROP/CREATE PROCEDURE, it could be possible for AtEOXact_PgStat_DroppedStats(), that wants to do transactional drops, to find entries that are already dropped, after a commit record has been written. In this case, ERRORs are upgraded to PANIC, taking down the server. This issue is fixed by making pgstat_drop_entry() optionally more tolerant to concurrent drops, adding to the routine a missing_ok option to make some of its callers more tolerant (spoiler: some of the callers want a strict behavior, like replication slots and backend stats). pgstat_drop_entry_internal() cannot be called anymore for an entry marked as dropped, hence its error is replaced by an assertion. Functions are handled as a special case in core; this problem could also apply to custom stats kinds depending on what an extension does. track_functions is costly when enabled (disabled by default), which is perhaps the main reason why this has not be found yet. A similar version of this patch has been proposed by Sami Imseih on a different thread for a feature in development. This version has tweaked here by me for the sake of fixing this issue. Reported-by: zhanglihui <zlh21343@163.com> Author: Sami Imseih <samimseih@gmail.com> Author: Michael Paquier <michael@paquier.xyz> Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Discussion: https://postgr.es/m/19520-73873648d44793cf@postgresql.org Backpatch-through: 15 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/2e0c61aed6241bb66547bfab7467d43f889f78ba Modified Files -------------- src/backend/utils/activity/pgstat_function.c | 2 +- src/backend/utils/activity/pgstat_replslot.c | 2 +- src/backend/utils/activity/pgstat_shmem.c | 27 +++++++++++++++++++-------- src/backend/utils/activity/pgstat_xact.c | 8 ++++---- src/include/utils/pgstat_internal.h | 3 ++- 5 files changed, 27 insertions(+), 15 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix PANIC with track_functions due to concurrent drop of pgstats @ 2026-06-18 02:50 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 5+ messages in thread From: Michael Paquier @ 2026-06-18 02:50 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix PANIC with track_functions due to concurrent drop of pgstats entries pgstat_drop_entry_internal() generates an ERROR if facing a pgstats entry already marked as dropped. With a workload doing a lot of concurrent CALL and DROP/CREATE PROCEDURE, it could be possible for AtEOXact_PgStat_DroppedStats(), that wants to do transactional drops, to find entries that are already dropped, after a commit record has been written. In this case, ERRORs are upgraded to PANIC, taking down the server. This issue is fixed by making pgstat_drop_entry() optionally more tolerant to concurrent drops, adding to the routine a missing_ok option to make some of its callers more tolerant (spoiler: some of the callers want a strict behavior, like replication slots and backend stats). pgstat_drop_entry_internal() cannot be called anymore for an entry marked as dropped, hence its error is replaced by an assertion. Functions are handled as a special case in core; this problem could also apply to custom stats kinds depending on what an extension does. track_functions is costly when enabled (disabled by default), which is perhaps the main reason why this has not be found yet. A similar version of this patch has been proposed by Sami Imseih on a different thread for a feature in development. This version has tweaked here by me for the sake of fixing this issue. Reported-by: zhanglihui <zlh21343@163.com> Author: Sami Imseih <samimseih@gmail.com> Author: Michael Paquier <michael@paquier.xyz> Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Discussion: https://postgr.es/m/19520-73873648d44793cf@postgresql.org Backpatch-through: 15 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/bf4616b598a36bfb606c7bd81c0991d895577cb3 Modified Files -------------- src/backend/utils/activity/pgstat_function.c | 2 +- src/backend/utils/activity/pgstat_replslot.c | 2 +- src/backend/utils/activity/pgstat_shmem.c | 27 +++++++++++++++++++-------- src/backend/utils/activity/pgstat_xact.c | 8 ++++---- src/include/utils/pgstat_internal.h | 3 ++- 5 files changed, 27 insertions(+), 15 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix PANIC with track_functions due to concurrent drop of pgstats @ 2026-06-18 02:50 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 5+ messages in thread From: Michael Paquier @ 2026-06-18 02:50 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix PANIC with track_functions due to concurrent drop of pgstats entries pgstat_drop_entry_internal() generates an ERROR if facing a pgstats entry already marked as dropped. With a workload doing a lot of concurrent CALL and DROP/CREATE PROCEDURE, it could be possible for AtEOXact_PgStat_DroppedStats(), that wants to do transactional drops, to find entries that are already dropped, after a commit record has been written. In this case, ERRORs are upgraded to PANIC, taking down the server. This issue is fixed by making pgstat_drop_entry() optionally more tolerant to concurrent drops, adding to the routine a missing_ok option to make some of its callers more tolerant (spoiler: some of the callers want a strict behavior, like replication slots and backend stats). pgstat_drop_entry_internal() cannot be called anymore for an entry marked as dropped, hence its error is replaced by an assertion. Functions are handled as a special case in core; this problem could also apply to custom stats kinds depending on what an extension does. track_functions is costly when enabled (disabled by default), which is perhaps the main reason why this has not be found yet. A similar version of this patch has been proposed by Sami Imseih on a different thread for a feature in development. This version has tweaked here by me for the sake of fixing this issue. Reported-by: zhanglihui <zlh21343@163.com> Author: Sami Imseih <samimseih@gmail.com> Author: Michael Paquier <michael@paquier.xyz> Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Discussion: https://postgr.es/m/19520-73873648d44793cf@postgresql.org Backpatch-through: 15 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1e9e62193c3fa66e39b50163f225388fcf6eb7d5 Modified Files -------------- src/backend/utils/activity/pgstat_function.c | 2 +- src/backend/utils/activity/pgstat_replslot.c | 2 +- src/backend/utils/activity/pgstat_shmem.c | 27 +++++++++++++++++++-------- src/backend/utils/activity/pgstat_xact.c | 8 ++++---- src/include/utils/pgstat_internal.h | 3 ++- 5 files changed, 27 insertions(+), 15 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2026-06-18 02:50 UTC | newest] Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-06-18 02:50 pgsql: Fix PANIC with track_functions due to concurrent drop of pgstats Michael Paquier <michael@paquier.xyz> 2026-06-18 02:50 pgsql: Fix PANIC with track_functions due to concurrent drop of pgstats Michael Paquier <michael@paquier.xyz> 2026-06-18 02:50 pgsql: Fix PANIC with track_functions due to concurrent drop of pgstats Michael Paquier <michael@paquier.xyz> 2026-06-18 02:50 pgsql: Fix PANIC with track_functions due to concurrent drop of pgstats Michael Paquier <michael@paquier.xyz> 2026-06-18 02:50 pgsql: Fix PANIC with track_functions due to concurrent drop of pgstats Michael Paquier <michael@paquier.xyz>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox