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 874lk3c8hr.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Toast issues with OldestXmin going backwards  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Toast issues with OldestXmin going backwards
List pgsql-hackers
>>>>> "Amit" == Amit Kapila <amit.kapila16@gmail.com> writes:

 Amit> I haven't tried to reproduce it, but I can see the possibility of
 Amit> the problem described by you. What should we do next? I could see
 Amit> few possibilities: (a) Vacuum for main and toast table should
 Amit> always use same OldestXmin,
 
 >> I don't see how this could be arranged without either disabling the
 >> ability to vacuum the toast table independently, or storing the xmin
 >> somewhere.

 Amit> I think we can use the same xmin for both main heap and toast

But you're completely missing the point here, which is that the main
heap might not be vacuumed AT ALL. Autovacuum can and will call vacuum()
with the relid of a toast table - this is a deliberate decision to cope
with access patterns that would otherwise bloat the toast table.

(It's also currently legal to do VACUUM pg_toast.pg_toast_nnnn;
manually, but that's of secondary importance compared to the fact that
autovacuum does it.)

 Amit> by computing it before scanning the main heap (lazy_vacuum_rel)
 Amit> and then pass it down. I have tried it and came up with the
 Amit> attached patch.

Your patch would actually be needed if (and only if) autovacuum was
changed back to its old behavior of never vacuuming toast tables
independently, and if manual VACUUM pg_toast.*; was disabled. But in the
presence of either of those two possibilities, it does nothing useful.

 >> Toast pointers don't point to TIDs fortunately, they point to OIDs.
 >> The OID could have been reused (if there's been an OID wraparound
 >> since the toast item was created), but that should be harmless: it
 >> means that we'd incorrectly copy the new value with the old tuple,
 >> but the old tuple is never going to be visible to anybody ever again
 >> so nothing will see that.

 Amit> Yeah, that's right, but it gives some uneasy feeling that we are
 Amit> attaching the wrong toast value. If you think there is some basic
 Amit> flaw in Approach-1 (as in attached patch) or it requires some
 Amit> major surgery then we can look further into this.

The basic flaw is that it doesn't even reach the problem.

-- 
Andrew (irc:RhodiumToad)


pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: BGWORKER_BYPASS_ALLOWCONN used nowhere (infra part of on-line checksum switcher)
Next
From: Noah Misch
Date:
Subject: Re: pg_recvlogical broken in back branches