On Thu, Apr 2, 2015 at 3:59 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Apr 2, 2015 at 2:55 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Actually, now that I think it through, the "could not open relation" >>> error is pretty odd in itself. If we are trying to open pg_am using >>> a stale catalog snapshot, it seems like we ought to reliably find its >>> old pg_class tuple (the one with the obsolete relfilenode), rather than >>> finding nothing. But the latter is the behavior I'm seeing. > >> What's to stop the old tuple from being HOT-pruned? > > Hm, that may be it. I went back to the previous test scenario, and now > I can *only* get the "cache lookup failed for access method" behavior, > instead of what I was getting before, so I'm getting a bit confused :-(. > However, it does seem clear that the mechanism is indeed that we're > relying on an obsolete copy of pg_am's pg_class tuple, hence scanning a > truncated relfilenode, and that the patch I proposed fixes it. > > Perhaps the difference has to do with whether pg_am's pg_class tuple is > on a page that hasn't got enough room for a HOT update? But I definitely > tried it several times and consistently got the same failure before.
That seems plausible, except that I have no idea why that would vary from one test setup to another. I suggest pushing the patch you proposed upthread and seeing what the buildfarm thinks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
