RE: strange slow query - lost lot of time somewhere
От | Jakub Wartak |
---|---|
Тема | RE: strange slow query - lost lot of time somewhere |
Дата | |
Msg-id | AM8PR07MB8248D8EA216ACD440EB63E60F6C29@AM8PR07MB8248.eurprd07.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: strange slow query - lost lot of time somewhere (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: strange slow query - lost lot of time somewhere
|
Список | pgsql-hackers |
Hi Pavel, > I have not debug symbols, so I have not more details now > Breakpoint 1 at 0x7f557f0c16c0 > (gdb) c > Continuing. > Breakpoint 1, 0x00007f557f0c16c0 in mmap64 () from /lib64/libc.so.6 > (gdb) bt > #0 0x00007f557f0c16c0 in mmap64 () from /lib64/libc.so.6 > #1 0x00007f557f04dd91 in sysmalloc () from /lib64/libc.so.6 > #2 0x00007f557f04eaa9 in _int_malloc () from /lib64/libc.so.6 > #3 0x00007f557f04fb1e in malloc () from /lib64/libc.so.6 > #4 0x0000000000932134 in AllocSetAlloc () > #5 0x00000000009376cf in MemoryContextAllocExtended () > #6 0x00000000006ad915 in ExecInitMemoize () Well the PGDG repo have the debuginfos (e.g. postgresql14-debuginfo) rpms / dpkgs(?) so I hope you are basically 1 commandaway of being able to debug it further what happens in ExecInitMemoize() Those packages seem to be safe as they modify only /usr/lib/debug so should not have any impact on production workload. -J.
В списке pgsql-hackers по дате отправления: