Re: [HACKERS] Block level parallel vacuum
| От | Amit Kapila |
|---|---|
| Тема | Re: [HACKERS] Block level parallel vacuum |
| Дата | |
| Msg-id | CAA4eK1L-Y7vyo+ypH55kFHy1HS=4h1ZWQ+5fthKBgOdQzz4hOw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Block level parallel vacuum (Prabhat Sahu <prabhat.sahu@enterprisedb.com>) |
| Список | pgsql-hackers |
On Fri, Dec 20, 2019 at 5:17 PM Prabhat Sahu <prabhat.sahu@enterprisedb.com> wrote:
Hi,
While testing this feature with parallel vacuum on "TEMPORARY TABLE", I got a server crash on PG Head+V36_patch.
From the call stack, it is not clear whether it is related to a patch at all. Have you checked your test with and without the patch? The reason is that the patch doesn't perform a parallel vacuum on temporary tables.
Changed configuration parameters and Stack trace are as below:
-- Stack trace:
[centos@parallel-vacuum-testing bin]$ gdb -q -c data/core.1399 postgres
Reading symbols from /home/centos/BLP_Vacuum/postgresql/inst/bin/postgres...done.
[New LWP 1399]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `postgres: autovacuum worker postgres '.
Program terminated with signal 6, Aborted.
#0 0x00007f4517d80337 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-292.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-37.el7_7.2.x86_64 libcom_err-1.42.9-16.el7.x86_64 libgcc-4.8.5-39.el7.x86_64 libselinux-2.5-14.1.el7.x86_64 openssl-libs-1.0.2k-19.el7.x86_64 pcre-8.32-17.el7.x86_64 zlib-1.2.7-18.el7.x86_64
(gdb) bt
#0 0x00007f4517d80337 in raise () from /lib64/libc.so.6
#1 0x00007f4517d81a28 in abort () from /lib64/libc.so.6
#2 0x0000000000a96341 in ExceptionalCondition (conditionName=0xd18efb "strvalue != NULL", errorType=0xd18eeb "FailedAssertion",
fileName=0xd18ee0 "snprintf.c", lineNumber=442) at assert.c:67
#3 0x0000000000b02522 in dopr (target=0x7ffdb0e38450, format=0xc5fa95 ".%s\"", args=0x7ffdb0e38538) at snprintf.c:442
#4 0x0000000000b01ea6 in pg_vsnprintf (str=0x256df50 "autovacuum: dropping orphan temp table \"postgres.", '\177' <repeats 151 times>..., count=1024,
fmt=0xc5fa68 "autovacuum: dropping orphan temp table \"%s.%s.%s\"", args=0x7ffdb0e38538) at snprintf.c:195
#5 0x0000000000afbadf in pvsnprintf (buf=0x256df50 "autovacuum: dropping orphan temp table \"postgres.", '\177' <repeats 151 times>..., len=1024,
fmt=0xc5fa68 "autovacuum: dropping orphan temp table \"%s.%s.%s\"", args=0x7ffdb0e38538) at psprintf.c:110
#6 0x0000000000afd34b in appendStringInfoVA (str=0x7ffdb0e38550, fmt=0xc5fa68 "autovacuum: dropping orphan temp table \"%s.%s.%s\"", args=0x7ffdb0e38538)
at stringinfo.c:149
#7 0x0000000000a970fd in errmsg (fmt=0xc5fa68 "autovacuum: dropping orphan temp table \"%s.%s.%s\"") at elog.c:832
#8 0x00000000008588d2 in do_autovacuum () at autovacuum.c:2249
The call stack seems to indicate that the backend from where you were doing the operations on temporary tables seems to have crashed somehow and then autovacuum tries to clean up that orphaned temporary table. And it crashes while printing the message for dropping orphan tables. Below is that message:
(errmsg("autovacuum: dropping orphan temp table \"%s.%s.%s\"",
get_database_name(MyDatabaseId),
get_namespace_name(classForm->relnamespace),
NameStr(classForm->relname))));
Now it can fail the assertion only if one of three parameters (database name, namespace, relname) is NULL which I can't see any way to happen unless you have manually removed one of namespace or database.
(gdb)
I have tried to reproduce the same with all previously executed queries but now I am not able to reproduce the same.
I am not sure how from this we can conclude if there is any problem with this patch or otherwise unless you have some steps to show us what you have done. It could happen if you somehow corrupt the database by manually removing stuff or maybe there is some genuine bug, but it is not at all clear.
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Tomas VondraДата:
Сообщение: Re: [PATCH] Increase the maximum value track_activity_query_size
Следующее
От: Julien RouhaudДата:
Сообщение: Re: [PATCH] Increase the maximum value track_activity_query_size