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
