Skip site navigation (1) Skip section navigation (2)

Re: rewriteheap.c bug: toast rows don't get XIDs matching their parents

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: rewriteheap.c bug: toast rows don't get XIDs matching their parents
Date: 2012-01-27 18:48:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
> 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.

Robert Haas
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Sergey KonoplevDate: 2012-01-27 19:42:46
Subject: Re: pg_statistic, lack of documentation
Previous:From: Robert HaasDate: 2012-01-27 18:45:28
Subject: Re: Intermittent regression test failures from index-only plan changes

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group