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

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.


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:

Reply via email to