Re: TOAST versus VACUUM, or "missing chunk number 0 for toast value" identified

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Andrew Hammond" <andrew(dot)george(dot)hammond(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TOAST versus VACUUM, or "missing chunk number 0 for toast value" identified
Date: 2011-10-28 19:54:26
Message-ID: 4EAAC222020000250004283C@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> The risk factor comes in when we hold a syscache entry across
> transactions; then this guarantee is lost. (In both the original
> example and the pg_proc case above, the second backend is only at
> risk when it starts its transaction after the first one's commit,
> and in between VACUUM was able to compute an OldestXmin greater
> than the first one's XID.)

If we made the commit sequence number more generally available,
incrementing it at the point of visibility change under cover of
ProcArrayLock, and including the then-current value in a Snapshot
object when built, would that help with this at all? Since it's
something we might need to do to optimize SSI for 9.2, and the
issues sound vaguely echoic of the reasons this is maintained for
SSI, it seems worth asking the question, anyway.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-10-28 19:58:11 Re: TOAST versus VACUUM, or "missing chunk number 0 for toast value" identified
Previous Message Robert Haas 2011-10-28 19:54:16 Re: pg_upgrade if 'postgres' database is dropped