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
