Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

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