Re: Autovaccuum vs temp tables crash

On Sat, Feb 23, 2019 at 12:29 AM Michael Paquier <michael(at)paquier(dot)xyz>
wrote:

> On Fri, Feb 22, 2019 at 09:45:42AM -0500, Tom Lane wrote:
> > +1 ... maybe "(dropped)", because we tend to use parens for this sort
> > of thing, I think.
>
> +1. Using "dropped" sounds good to me in this context. Perhaps we
> could have something more fancy like what's used for dropped columns?
> It would be nice to get a reference to a schema, like say "dropped
> temporary schema".
>

I think that's unnecessary given the context:

2019-02-23 15:43:56.375 CET [17250] LOG: autovacuum: dropping orphan temp
table "postgres.(dropped).bar"

That said, it just moves the crash. Turns out the problem goes a lot deeper
than just the logging, it's basically the cleanup of orphaned temp tables
that's completely broken if you drop the namespace.

TRAP: FailedAssertion("!(relation->rd_backend != (-1))", File:
"relcache.c", Line: 1085)
2019-02-23 15:43:56.378 CET [17146] LOG: server process (PID 17250) was
terminated by signal 6: Aborted

#2 0x0000563e0fe4bc83 in ExceptionalCondition
(conditionName=conditionName(at)entry=0x563e10035fb0 "!(relation->rd_backend
!= (-1))",
errorType=errorType(at)entry=0x563e0fe9bf9d "FailedAssertion",
fileName=fileName(at)entry=0x563e100357dc "relcache.c",
lineNumber=lineNumber(at)entry=1085) at assert.c:54
#3 0x0000563e0fe40e18 in RelationBuildDesc (targetRelId=24580,
insertIt=insertIt(at)entry=true) at relcache.c:1085
#4 0x0000563e0fe41a86 in RelationIdGetRelation (relationId=<optimized
out>, relationId(at)entry=24580) at relcache.c:1894
#5 0x0000563e0fa24b4c in relation_open (relationId=relationId(at)entry=24580,
lockmode=lockmode(at)entry=8) at relation.c:59
#6 0x0000563e0fadcfea in heap_drop_with_catalog (relid=24580) at
heap.c:1856
#7 0x0000563e0fad9145 in doDeletion (flags=21, object=<optimized out>) at
dependency.c:1329
#8 deleteOneObject (flags=21, depRel=0x7ffd80db4808, object=<optimized
out>) at dependency.c:1231
#9 deleteObjectsInList (targetObjects=targetObjects(at)entry=0x563e10640110,
depRel=depRel(at)entry=0x7ffd80db4808, flags=flags(at)entry=21)
at dependency.c:271
#10 0x0000563e0fad91f0 in performDeletion (object=object(at)entry=0x7ffd80db4944,
behavior=behavior(at)entry=DROP_CASCADE,
flags=flags(at)entry=21) at dependency.c:352
#11 0x0000563e0fa13532 in do_autovacuum () at autovacuum.c:2269

So basically I think it's the wrong approach to try to fix this error
message. We need to fix the underlying problem. Which is the ability to
drop the temp table schemas and then create temp tables which ahve no
schemas.

We could try to recreate the namespace if dropped. But a quick fix around
that just moved coredumps around to a lot of other dependent places.

I think we're better off just peventing the explicit drop of a temp schema.
See attached?

We'd also want to block things like:
ALTER SCHEMA pg_temp_3 RENAME TO foobar;
DROP SCHEMA foobar;

Are there any more things beyond RENAME we need to block?

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