Re: TRUNCATE SERIALIZABLE and frozen COPY

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kevin Grittner <kgrittn(at)mail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TRUNCATE SERIALIZABLE and frozen COPY
Date: 2012-11-09 16:57:29
Message-ID: CA+TgmoY4D_6X7AGtYU+H54=P0r=jR-n_K=6HeyBzsFbw0TodKA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 9, 2012 at 9:22 AM, Kevin Grittner <kgrittn(at)mail(dot)com> wrote:
> (1) Any attempt to read from the truncated table would not block. The
> pg_class version included in the transaction's snapshot would
> determine which heap and indexes were accessed.

Well, the thing is, you can't actually do this. When the transaction
commits, we truncate the main forks of the old heap and index and
remove all of the supplemental forks. The main forks are finally
removed for good at the next checkpoint cycle. To make this work,
we'd have to keep around the old heap and index until there were no
longer any MVCC snapshots that could see them. That might be useful
as an option, but it would need a bunch of additional mechanism, and
it doesn't seem desirable as a default behavior because it could defer
disk space reclamation indefinitely.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-11-09 17:09:29 Re: TRUNCATE SERIALIZABLE and frozen COPY
Previous Message Tom Lane 2012-11-09 16:27:41 Re: TRUNCATE SERIALIZABLE and frozen COPY