Re: Toast issues with OldestXmin going backwards - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Toast issues with OldestXmin going backwards
Date
Msg-id 87o9iabtkt.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Toast issues with OldestXmin going backwards  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
>>>>> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes:

 Andrew> Since the tuple was vacuumable at that point, it will never
 Andrew> again become visible in any snapshot, so the only code that
 Andrew> should ever access its toast values is vacuum full/cluster,

and, unfortunately, CREATE INDEX (non-concurrently), including the index
build done by vacfull/cluster itself, which rather messes things up
because the toasted column might be a parameter to a functional index, or it
might itself be an indexed column (within a narrow size range for btree,
or more generally for other index types); this means the index AM or the
indexed function may try and actually detoast and inspect the value.

So right now it's possible (I think) in the worst case to crash the
server if you can set up exactly the right circumstances (re-use of a
prematurely vacuumed toast oid after wraparound, with the new value
matching the old value's raw length but not its compression state).

(My changes so far don't address this case and don't make it either more
or less likely)

-- 
Andrew (irc:RhodiumToad)


pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [HACKERS] path toward faster partition pruning
Next
From: Amit Langote
Date:
Subject: using expression syntax for partition bounds (was: Re: Booleanpartitions syntax)