Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Дата
Msg-id 95bdc353-1a89-3fe3-1181-eba558c4df83@BlueTreble.com
обсуждение исходный текст
Ответ на Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 8/16/16 11:59 AM, Robert Haas 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.

Some discussion about TEMP functions is happening on -general right now, 
and there's other things where temp objects are good to have, so it'd be 
nice to have a more generic fix for this stuff. Is the idea of 
"partitioning" the catalogs to store temp objects separate from 
permanent fatally flawed?
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: anyelement -> anyrange
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Keeping CURRENT_DATE and similar constructs in original format