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
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
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
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: