On 2016-06-16 12:02:39 -0400, Robert Haas wrote: > On Thu, Jun 16, 2016 at 11:37 AM, Andres Freund <and...@anarazel.de> wrote: > >> If that were really true, why would we not have the problem in > >> current production versions that the toast table could be vacuumed > >> before the heap, leading to exactly the issue you are talking > >> about? > > > > The issue isn't there without the feature, because we (should) never > > access a tuple/detoast a column when it's invisible enough for the > > corresponding toast tuple to be vacuumed away. But with > > old_snapshot_timeout that's obviously (intentionally) not the case > > anymore. Due to old_snapshot_threshold we'll prune tuples which, > > without it, would still be considered HEAPTUPLE_RECENTLY_DEAD. > > Is there really an assumption that the heap and the TOAST heap are > only ever vacuumed with the same OldestXmin value? Because that seems > like it would be massively flaky.
There's not. They can be vacuumed days apart. But if we vacuum the toast table with an OldestXmin, and encounter a dead toast tuple, by the definition of OldestXmin (excluding STO), there cannot be a session reading the referencing tuple anymore - so that shouldn't matter. IIRC we actually reverted a patch that caused significant problems around this. I think there's a small race condition around ProcessStandbyHSFeedbackMessage(), and you can restart with a different vacuum_defer_cleanup_age (we should just remove that), but other than that we shouldn't run into any issues without STO. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
