Re: Prepare Transaction support for ON COMMIT DROP temporary tables

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Prepare Transaction support for ON COMMIT DROP temporary tables
Дата
Msg-id CA+Tgmobuiv45opLOrn6oonNPfTXafz9Bc0bZJ546fEK+XpRbAQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Prepare Transaction support for ON COMMIT DROP temporary tables  (Dimitri Fontaine <dimitri@citusdata.com>)
Ответы Re: Prepare Transaction support for ON COMMIT DROP temporary tables  (Vik Fearing <vik.fearing@2ndquadrant.com>)
Список pgsql-hackers
On Mon, Jan 14, 2019 at 1:41 PM Dimitri Fontaine <dimitri@citusdata.com> wrote:
> One idea would be that if every temp table in the session belongs to the
> transaction, and their namespace too (we could check through pg_depend
> that the namespace doesn't contain anything else beside the
> transaction's tables), then we could dispose of the temp schema and
> on-commit-drop tables at PREPARE COMMIT time.

Why not just drop any on-commit-drop tables at PREPARE TRANSACTION
time and leave the schema alone?  If there are any temp tables touched
by the transaction which are not on-commit-drop then we'd have to
fail, but as long as all the tables we've got are on-commit-drop then
it seems fine to just nuke them at PREPARE time.  Such tables must've
been created in the current transaction, because otherwise the
creating transaction aborted and they're gone for that reason, or it
committed and they're gone because they're on-commit-drop.  And
regardless of whether the transaction we are preparing goes on to
commit or abort, those tables will be gone afterwards for the same
reasons.  So there doesn't in this case seem to be any reason to keep
them around until the transaction's fate is known.

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


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

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: WIP: Avoid creation of the free space map for small tables
Следующее
От: Andreas Karlsson
Дата:
Сообщение: Re: [HACKERS] REINDEX CONCURRENTLY 2.0