Autovaccuum vs temp tables crash

The following sequence causes autovacuum to crash on master:

CREATE TEMP TABLE foo(a int);
DROP TABLE foo;
DROP SCHEMA pg_temp_3;
CREATE TEMP TABLE bar(a int);
DROP TABLE bar;

it coredumps with:

#1 0x00007f96b5daa42a in __GI_abort () at abort.c:89
#2 0x000055d997915ba3 in ExceptionalCondition
(conditionName=conditionName(at)entry=0x55d997b2a05f "!(strvalue != ((void
*)0))",
errorType=errorType(at)entry=0x55d997965ebd "FailedAssertion",
fileName=fileName(at)entry=0x55d997b2a054 "snprintf.c",
lineNumber=lineNumber(at)entry=442) at assert.c:54
#3 0x000055d99795e4ec in dopr (target=target(at)entry=0x7ffc04f479e0,
format=0x55d997abfa2d ".%s\"",
format(at)entry=0x55d997abfa00 "autovacuum: dropping orphan temp table
\"%s.%s.%s\"", args=<optimized out>) at snprintf.c:442
#4 0x000055d99795e6ce in pg_vsnprintf (str=<optimized out>,
count=<optimized out>, count(at)entry=1024,
fmt=fmt(at)entry=0x55d997abfa00 "autovacuum: dropping orphan temp table
\"%s.%s.%s\"", args=args(at)entry=0x7ffc04f47a88)
at snprintf.c:195
#5 0x000055d997963c21 in pvsnprintf (buf=<optimized out>, len=len(at)entry
=1024,
fmt=fmt(at)entry=0x55d997abfa00 "autovacuum: dropping orphan temp table
\"%s.%s.%s\"", args=args(at)entry=0x7ffc04f47a88)
at psprintf.c:110
#6 0x000055d9976deef8 in appendStringInfoVA (str=str(at)entry=0x7ffc04f47a70,
fmt=fmt(at)entry=0x55d997abfa00 "autovacuum: dropping orphan temp table
\"%s.%s.%s\"", args=args(at)entry=0x7ffc04f47a88)
at stringinfo.c:136
#7 0x000055d997919b60 in errmsg (fmt=fmt(at)entry=0x55d997abfa00 "autovacuum:
dropping orphan temp table \"%s.%s.%s\"") at elog.c:794
#8 0x000055d9974dd551 in do_autovacuum () at autovacuum.c:2255

We are certainly not supposed to go DROP SCHEMA on the temp namespaces, but
we are also not supposed to coredump on it (if we were, we should prevent
people from DROP SCHEMA it and we don't).

In fact, we probably *should* prevent the dropping of the temp schema? But
that's independent from fixing this one.

The reason for the crash is 6d842be6c11, where Tom added an assert for
passing null into %s. But I don't think we can blame that patch for the
problem -- it's passing the NULL there in the first place that's the
problem.

AFAICT the actual drop works fine, it's just the logging that crashes. So
maybe we should just add a check and make it log something like "<dropped>"
if pg_namespace_name() returns null?

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>