Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables) - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Date
Msg-id 20160817125059.0fb42420@e733
Whole thread Raw
In response to Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
> 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. 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!

-- 
Best regards,
Aleksander Alekseev



pgsql-hackers by date:

Previous
From: Victor Wagner
Date:
Subject: Re: Use pread and pwrite instead of lseek + write and read
Next
From: Aleksander Alekseev
Date:
Subject: Re: [GENERAL] C++ port of Postgres