On Wed, Jun 15, 2016 at 5:34 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-06-15 16:58:25 -0500, Kevin Grittner wrote:
>> On Wed, Jun 15, 2016 at 3:25 PM, Andres Freund <andres@anarazel.de> wrote:
>>> On 2016-06-15 14:24:58 -0500, Kevin Grittner wrote:
>>>> On Wed, Jun 15, 2016 at 2:20 PM, Andres Freund <andres@anarazel.de> wrote:
>>>>
>>>>> We might fetch a toast tuple which
>>>>> since have been re-purposed for a datum of a different type.
>>>>
>>>> How would that happen?
>>>
>>> Autovac vacuums toast and heap tables independently. Once a toast datum
>>> isn't used anymore, the oid used can be reused (because it doesn't
>>> conflict via GetNewOidWithIndex() anymore. If analyze then detoasts a
>>> datum, which hasn't been removed, the contents of that toast id, might
>>> actually be for something different.
>>
>> What prevents that from happening now, without STO?
>
> Afaics we shouldn't ever look (i.e. detoast) at a "dead for everyone"
> tuple in autovacuum (or anywhere else). There's one minor exception to
> that, and that's enum datums in indexes, which is why we currently have
> weird transactional requirements for them. I'm not entirely sure this
> can be hit, but it's worth checking.
I'm not clear where you see this as being in any way different with
STO. Above it seemed that you saw this as an issue related to
ANALYZE. If there is not early pruning for the table being
analyzed, nothing is at all different. If there is early pruning
the rows are not seen and there could be no detoasting. If there
is a function that lies about IMMUTABLE and reads from a table, it
either functions as before or throws a STO error on page access
(long before any detoasting). Am I missing something?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company