Re: Toast issues with OldestXmin going backwards

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Toast issues with OldestXmin going backwards
Date: 2018-04-22 20:25:06
Message-ID: 874lk3c8hr.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Amit" == Amit Kapila <amit(dot)kapila16(at)gmail(dot)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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2018-04-22 21:55:51 Re: pg_recvlogical broken in back branches
Previous Message Daniel Gustafsson 2018-04-22 13:56:32 Re: BGWORKER_BYPASS_ALLOWCONN used nowhere (infra part of on-line checksum switcher)