Pg_stat_monitor 2.1 causes PG17.6 to segfault

PostgreSQL pg_stat_monitor
1 
(gdb) f
#0  0x00007f2fd416ea7c in __strlen_evex () from /lib64/libc.so.6
(gdb) bt full
#0  0x00007f2fd416ea7c in __strlen_evex () from /lib64/libc.so.6
No symbol table info available.
#1  0x00000000007b8300 in CleanQuerytext ()
#2  0x00007f2fd3e62eae in pgsm_ProcessUtility () from /usr/pgsql-17/lib/pg_stat_monitor.so
#3  0x00007f2fd3e42d6c in pgaudit_ProcessUtility_hook () from /usr/pgsql-17/lib/pgaudit.so
#4  0x00000000008fb48a in PortalRunUtility ()
#5  0x00000000008fb917 in FillPortalStore ()
#6  0x00000000008fbc6d in PortalRun ()
#7  0x00000000008fd594 in PostgresMain ()
#8  0x00000000008f3f15 in BackendMain ()
#9  0x00000000008580f4 in postmaster_child_launch.part ()
#10 0x000000000086403a in ServerLoop ()
#11 0x0000000000864d99 in PostmasterMain ()
#12 0x0000000000525985 in main ()

It looks as if __strlen_evex cannot handle UTF8 properly. I don’t have data that caused this though. Disabled pg_stat_monitor for now.

2

Welcome and thanks for the bug report! I have a few questions so I can find the bug easier.

  1. Do you have any other extensions installed? This bug could possibly be caused by a bad interaction between two extensions. Of course if this is the case it is a possibility that it still can be fixed in pg_stat_monitor.

  2. What makes you suspect that it is UTF-8 related because when I look at the code I do not see any reason to suspect that it would be encoding related? Do you maybe have a query which makes you suspect so?

  3. Do you have a some query or set of queries which consistently can reproduce this bug?

Thanks!

3

Reported the bug in our bug tracker so that it is not lost: PG-1950

4

Hello Andreas,

Thank You for reply.

  1. Yes. I got the failure when shared_preload_libraries = ‘pg_stat_statements,pg_stat_monitor,auto_explain,pg_qualstats,pgaudit,pg_cron’.

  2. That is just my suspicion. In past, I’ve run into problems measuring string length on UTF8 strings containing NULL char in the past. There’s no proof for this case though.

  3. I’ve tried, but cannot reproduce the bug. It looks like the data vanishes once our vendor completes app update . I’ll get one more chance though, two app updates are remaining. I’ll try to copy the DB in failing state.

  4. I think the best way to proceed is to just keep ticket open for, say, 2 months. Update should be completed by then.

Regards,
Petr.
1.

Od: Andreas Karlsson via Percona Community Forum notifications@percona1.discoursemail.com
Komu: Duchoň Petr pduchon@koop.cz
Předmět: [Percona Community Forum] Pg_stat_monitor 2.1 causes PG17.6 to segfault


EXTERNÍ E-MAIL - Buďte opatrní při práci s přílohami a odkazy / EXTERNAL EMAIL
|

  • |

Your topic received a new reply. Check it out and let community members know if you appreciate their response:

  • Like the post if it is useful for you.
  • Mark it as Solution if it answers your question or resolves your issue.

Message:

Welcome and thanks for the bug report! I have a few questions so I can find the bug easier.

  1. Do you have any other extensions installed? This bug could possibly be caused by a bad interaction between two extensions.

  2. What makes you suspect that it is UTF-8 related because when I look at the code I do not see any reason to suspect that it would be encoding related? Do you maybe have a query which makes you suspect so?

  3. Do you have a some query or set of queries which consistently can reproduce this bug?

Thanks!

Thank you for your active participation in Percona open source community!

5

Hello Andreas,

I couldn’t (and won’t be able to) reproduce the bug. (suspicious data don’t survive DB copy and rollback after crash).
However: I’ve discovered that pg_stat_monitor lib got silently upgraded from 2.1 to 2.2, while its metadata stayed at 2.1. This might​ have caused the crash.
I’d suggest to close the post, at least for now.

Thank You,
Petr.