Re: Autovaccuum vs temp tables crash

On Sat, Feb 23, 2019 at 4:28 PM Magnus Hagander <magnus(at)hagander(dot)net> wrote:

>
>
> 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?
>
>
Ooh, RENAME has problems entirely unrelated to that:

ALTER SCHEMA pg_catalog RENAME TO foobar;

Yeah, that breaks things...

Renaming schemas only check that the *target* name is not reserved. Surely
it should also check that the *source* name is not reserved? (Unless
allowSystemTableMods)?

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