Re: [HACKERS] Block level parallel vacuum

On Fri, Dec 20, 2019 at 5:17 PM Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)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(at)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:

ereport(LOG,
(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.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com