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

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 (view raw or flat)
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

pgsql-hackers by date

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

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