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

From Robert Haas
Subject Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Date
Msg-id CA+TgmoaTbFPTWEzccd1p6k_v7WwmYGwMOZ3qJYhfQo0-JmyhNQ@mail.gmail.com
Whole thread Raw
In response to Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)  (Aleksander Alekseev <a.alekseev@postgrespro.ru>)
Responses Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)  (Aleksander Alekseev <a.alekseev@postgrespro.ru>)
List pgsql-hackers
On Mon, Aug 15, 2016 at 5:12 AM, Aleksander Alekseev
<a.alekseev@postgrespro.ru> wrote:
> Just to keep things sane I would like to remind that in this concrete
> patch there _are_ catalog entries:
>
> ```
> [...]
> This file contents imlementation of special type of temporary tables ---
> fast temporary tables (FTT). From user perspective they work exactly as
> regular temporary tables. However there are no records about FTTs in
> pg_catalog. These records are stored in backend's memory instead and
> mixed with regular records during scans of catalog tables. We refer to
> corresponding tuples of catalog tables as "in-memory" or "virtual"
> tuples and to all these tuples together --- as "in-memory" or "virtual"
> catalog.
> [...]
> ```

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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: [GENERAL] C++ port of Postgres
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] C++ port of Postgres