On Thu, Jun 16, 2016 at 11:54 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-06-16 12:43:34 -0400, Robert Haas wrote:
>> The root of my confusion is: if we prune a tuple, we'll bump the page
>> LSN, so any session that is still referencing that tuple will error
>> out as soon as it touches the page on which that tuple used to exist.
>
> Right. On the main table. But we don't peform that check on the toast
> table/pages. So if we prune toast tuples, which are still referenced by
> (unvacuumed) main relation, we can get into trouble.
I thought that we should never be using visibility information from
the toast table; that the visibility information in the heap should
control. If that's the case, how would we prune toast rows without
pruning the heap? You pointed out that the *reverse* case has an
option bit -- if that is ever set there could be toasted values
which would not have a row. Do they still have a line pointer in
the heap, like "dead" index entries? How are they cleaned up in
current production versions? (Note the question mark -- I'm not
big on using that with assertions and rarely fall back on
rhetorical questions.)
>> It won't even survive long enough to care that the tuple isn't there
>> any more.
>>
>> Maybe it would help if you lay out the whole sequence of events, like:
>>
>> S1: Does this.
>> S2: Does that.
>> S1: Now does something else.
>
> I presume it'd be something like:
>
> Assuming a 'toasted' table, which contains one row, with a 1GB field.
>
> S1: BEGIN REPEATABLE READ;
> S1: SELECT SUM(length(one_gb_record)) FROM toasted;
> S2: DELETE FROM toasted;
> AUTOVAC: vacuum toasted's toast table, it's large. skip toasted, it's small
> S1: SELECT SUM(length(one_gb_record)) FROM toasted;
> <missing chunk error>
I'll put together a test like that and post in a bit.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
