On Thu, Jan 12, 2012 at 4:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> While working on bug #6393 I was reminded of the truth of $SUBJECT: any
> rows inserted into the new toast table will have the xmin of the CLUSTER
> or VACUUM FULL operation, and invalid xmax, whereas their parent heap
> rows will have xmin/xmax copied from the previous instance of the table.
> This does not matter much for ordinary live heap rows, but it's also
> necessary for CLUSTER/VACUUM FULL to copy recently-dead,
> insert-in-progress, and delete-in-progress rows. In such cases, a later
> plain VACUUM might reap the parent heap rows and not the toast rows,
> leading to a storage leak that won't be recovered short of another
> CLUSTER/VACUUM FULL.
> I can't remember if we discussed this risk when the heap rewrite code
> was written. I'm not sure it's worth fixing, but at the least it ought
> to be documented in the comments in rewriteheap.c.
People run CLUSTER and VACUUM FULL to recover wasted storage, so it's
a bit unfortunate if those operations can themselves introduce a
storage leak. So I think it would be nice to fix this, but if that's
more than we can manage right now, then I agree we should at least add
a code comment so that it has a better chance of getting fixed later.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Sergey Konoplev||Date: 2012-01-27 19:42:46|
|Subject: Re: pg_statistic, lack of documentation|
|Previous:||From: Robert Haas||Date: 2012-01-27 18:45:28|
|Subject: Re: Intermittent regression test failures from index-only