Autovaccuum vs temp tables crash - Mailing list pgsql-hackers

From Magnus Hagander
Subject Autovaccuum vs temp tables crash
Date
Msg-id CABUevEzcKjKFSciiuSR+jCZNrcPtPqokduFvrvPbb_0g2ZwMNw@mail.gmail.com
Whole thread Raw
Responses Re: Autovaccuum vs temp tables crash
Re: Autovaccuum vs temp tables crash
List pgsql-hackers
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@entry=0x55d997b2a05f "!(strvalue != ((void *)0))", 
    errorType=errorType@entry=0x55d997965ebd "FailedAssertion", fileName=fileName@entry=0x55d997b2a054 "snprintf.c", 
    lineNumber=lineNumber@entry=442) at assert.c:54
#3  0x000055d99795e4ec in dopr (target=target@entry=0x7ffc04f479e0, format=0x55d997abfa2d ".%s\"", 
    format@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@entry=1024, 
    fmt=fmt@entry=0x55d997abfa00 "autovacuum: dropping orphan temp table \"%s.%s.%s\"", args=args@entry=0x7ffc04f47a88)
    at snprintf.c:195
#5  0x000055d997963c21 in pvsnprintf (buf=<optimized out>, len=len@entry=1024, 
    fmt=fmt@entry=0x55d997abfa00 "autovacuum: dropping orphan temp table \"%s.%s.%s\"", args=args@entry=0x7ffc04f47a88)
    at psprintf.c:110
#6  0x000055d9976deef8 in appendStringInfoVA (str=str@entry=0x7ffc04f47a70, 
    fmt=fmt@entry=0x55d997abfa00 "autovacuum: dropping orphan temp table \"%s.%s.%s\"", args=args@entry=0x7ffc04f47a88)
    at stringinfo.c:136
#7  0x000055d997919b60 in errmsg (fmt=fmt@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?

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Unified logging system for command-line programs
Next
From: Jehan-Guillaume de Rorthais
Date:
Subject: Re: Using old master as new replica after clean switchover