From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: pgsql-hackers@postgresql.org
Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Date: Thu, 18 Aug 2016 16:30:45 +0200
Message-ID: <defa6ed8-be61-424d-5215-396591a779b6@2ndquadrant.com> (raw)
In-Reply-To: <20160817125059.0fb42420@e733>
References: <20160801124531.66cde374@fujitsu>
<26c3bc60-6613-e7ab-517a-53136f01fb6c@2ndquadrant.com>
<13191.1470072250@sss.pgh.pa.us>
<20160804151451.6fb87507@fujitsu>
<CA+Tgmob+AS4vPA-wp+KevL7q+qK4c7yZ5wjGvEv6EqPChE2oYQ@mail.gmail.com>
<CA+q6zcVLO7VoHHpRn9ExkiWksF6TwJ-rabqgwRJgC2_ci8_UEQ@mail.gmail.com>
<CA+TgmoYstEXxa0KCAPVAVseTwBpb51t=bK1FBU8L8h4sC3XWBQ@mail.gmail.com>
<14212.1470595566@sss.pgh.pa.us>
<20160815005755.gswdyjfob7dzw4yp@alap3.anarazel.de>
<20319.1471223097@sss.pgh.pa.us>
<20160815010852.5ijua2wm2edzimd4@alap3.anarazel.de>
<20160815121216.46bd758d@e733>
<CA+TgmoaTbFPTWEzccd1p6k_v7WwmYGwMOZ3qJYhfQo0-JmyhNQ@mail.gmail.com>
<20160817125059.0fb42420@e733>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 08/17/2016 11:50 AM, Aleksander Alekseev wrote:
>> That doesn't really solve the problem, because OTHER backends won't be
>> able to see them. So, if I create a fast temporary table in one
>> session that depends on a permanent object, some other session can
>> drop the permanent object. If there were REAL catalog entries, that
>> wouldn't work, because the other session would see the dependency.
>>
>
> This is a good point. However current implementation doesn't allow to
> do that.
IMHO without handling that, the design is effectively broken and has
very little change (or rather none at all) to get committed.
I think one way to fix that would be to store the virtual tuples in
shared memory (instead of process memory). That will certainly require
locking and synchronization, but well - it needs to be shared.
> There is a related bug though, a minor one.
>
> In session 1:
>
> ```
> CREATE TABLE cities2 (name text, population float, altitude int);
> CREATE FAST TEMPORARY TABLE capitals2 (state char(2)) INHERITS (cities2);
> ```
>
> In session 2:
>
> ```
> DROP TABLE cities2;
>
> ERROR: cache lookup failed for relation 16401
> ```
>
> Instead of "cache lookup failed" probably a better error message
> should be displayed. Something like "cannot drop table cities2
> because other objects depend on it". I will send a corrected patch
> shortly.
>
> Everything else seems to work as expected.
>
> If you discover any other bugs please let me know!
>
While a better error message would be nice, this is curing the symptoms
and not the cause. I think a proper design needs to prevent the DROP by
using dependencies.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@2ndquadrant.com
Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
In-Reply-To: <defa6ed8-be61-424d-5215-396591a779b6@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox