Re: TOAST versus VACUUM, or "missing chunk number 0 for toast value" identified - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: TOAST versus VACUUM, or "missing chunk number 0 for toast value" identified
Date
Msg-id 4EAAC222020000250004283C@gw.wicourts.gov
Whole thread Raw
In response to Re: TOAST versus VACUUM, or "missing chunk number 0 for toast value" identified  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: TOAST versus VACUUM, or "missing chunk number 0 for toast value" identified  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_upgrade if 'postgres' database is dropped
Next
From: Tom Lane
Date:
Subject: Re: TOAST versus VACUUM, or "missing chunk number 0 for toast value" identified