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
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 |