Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema

On Thu, 9 Jan 2020 at 09:36, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Wed, Jan 08, 2020 at 10:56:01AM +0900, Michael Paquier wrote:
> > And done this way as per the attached. I am of course open to
> > objections or better ideas, though this looks formulation looks pretty
> > good to me. Robert?
>
> Just to be clear here, I would like to commit this patch and backpatch
> with the current formulation in the error strings in the follow-up
> days. In 9.4~10, the error cannot be reached, but that feels safer if
> we begin to work again on this portion of the autovacuum code. So if
> you would like to object, that's the moment..
> --

Hi,
I reviewed and tested the patch. After applying patch, I am getting other
assert failure.

postgres=# CREATE TEMPORARY TABLE temp (a int);
CREATE TABLE
postgres=# \d
List of relations
Schema | Name | Type | Owner
-----------+------+-------+----------
pg_temp_3 | temp | table | mahendra
(1 row)

postgres=# drop schema pg_temp_3 cascade ;
NOTICE: drop cascades to table temp
DROP SCHEMA
postgres=# \d
Did not find any relations.
postgres=# CREATE TEMPORARY TABLE temp (a int);
CREATE TABLE
postgres=# \d
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
postgres=#

*Stack trace:*
(gdb) bt
#0 0x00007f7d749bd277 in __GI_raise (sig=sig(at)entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f7d749be968 in __GI_abort () at abort.c:90
#2 0x0000000000eca3c4 in ExceptionalCondition (conditionName=0x114cc08
"relation->rd_backend != InvalidBackendId", errorType=0x114ca8b
"FailedAssertion",
fileName=0x114c8b0 "relcache.c", lineNumber=1123) at assert.c:67
#3 0x0000000000eaacb9 in RelationBuildDesc (targetRelId=16392,
insertIt=true) at relcache.c:1123
#4 0x0000000000eadf61 in RelationIdGetRelation (relationId=16392) at
relcache.c:2021
#5 0x000000000049f370 in relation_open (relationId=16392, lockmode=8) at
relation.c:59
#6 0x000000000064ccda in heap_drop_with_catalog (relid=16392) at
heap.c:1890
#7 0x00000000006435f3 in doDeletion (object=0x2d623c0, flags=21) at
dependency.c:1360
#8 0x0000000000643180 in deleteOneObject (object=0x2d623c0,
depRel=0x7ffcb9636290, flags=21) at dependency.c:1261
#9 0x0000000000640d97 in deleteObjectsInList (targetObjects=0x2dce438,
depRel=0x7ffcb9636290, flags=21) at dependency.c:271
#10 0x0000000000640ed6 in performDeletion (object=0x7ffcb96363b0,
behavior=DROP_CASCADE, flags=21) at dependency.c:356
#11 0x0000000000aebc3d in do_autovacuum () at autovacuum.c:2269
#12 0x0000000000aea478 in AutoVacWorkerMain (argc=0, argv=0x0) at
autovacuum.c:1693
#13 0x0000000000ae9cf9 in StartAutoVacWorker () at autovacuum.c:1487
#14 0x0000000000b13cdc in StartAutovacuumWorker () at postmaster.c:5562
#15 0x0000000000b131b5 in sigusr1_handler (postgres_signal_arg=10) at
postmaster.c:5279
#16 <signal handler called>
#17 0x00007f7d74a7cc53 in __select_nocancel () at
../sysdeps/unix/syscall-template.S:81
#18 0x0000000000b09fc9 in ServerLoop () at postmaster.c:1691
#19 0x0000000000b09544 in PostmasterMain (argc=3, argv=0x2ce2290) at
postmaster.c:1400
#20 0x0000000000974b43 in main (argc=3, argv=0x2ce2290) at main.c:210

I think, before committing 1st patch, we should fix this crash also and
then we should commit all the patches.

Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com