Re: Partitioning with temp tables is broken

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Partitioning with temp tables is broken
Date: 2018-06-14 05:29:59
Message-ID: 44480bb1-a080-d8a3-644a-f78153f65a69@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2018/06/13 21:06, David Rowley wrote:
> There's also something pretty weird around the removal of the temp
> relation from the partition bound. I've had cases where the session
> that attached the temp table is long gone, but \d+ shows the table is
> still there and I can't attach another partition due to an overlap,
> and can't drop the temp table due to the session not existing anymore.
> I've not got a test case for that one yet, but the test case for the
> crash is:
>
> -- Session 1:
> create table listp (a int) partition by list(a);
> create table listp1 partition of listp for values in(1);
> create temp table listp2 partition of listp for values in (2);
>
> -- Session 2:
> select * from listp;

When Session 2 crashes (kill -9'ing it would also suffice), for some
reason, Session 1 doesn't get an opportunity to perform
RemoveTempRelationsCallback(). So, both the listp2's entry pg_class and
any references to it (such as its pg_inherits entry as partition of listp)
persist. listp2 won't be removed from the partition bound until all of
those catalog entries get removed.

Thanks,
Amit

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2018-06-14 05:30:55 Re: Postgres, fsync, and OSs (specifically linux)
Previous Message Atul Kumar 2018-06-14 05:28:53 question on streaming replication