On Thu, Apr 2, 2015 at 2:40 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Apr 2, 2015 at 12:54 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> It looks to me like an appropriate fix would be as attached; thoughts? > >> Hmm, that fix doesn't reach as far as what I did. My proposal would >> regard a catalog snapshot as immediately stale, so if we're asked for >> a catalog snapshot multiple times before InitPostgres() is called, >> we'll take a new one every time. Your proposal invalidates them just >> once, after setting up MyDatabaseId. Assuming yours is safe, it's >> better, because it invalidates less aggressively. > > Right. > >> The only thing I'm worried about is that I think >> PerformAuthentication() runs before InitPostgres(); sinval isn't >> working at all at that point, even for shared catalogs. > > No, PerformAuthentication is called by InitPostgres.
Oops, OK. > However, I'm having second thoughts about whether we've fully diagnosed > this. Three out of the four failures we've seen in the buildfarm reported > "cache lookup failed for access method 403", not "could not open relation > with OID 2601" ... and I'm so far only able to replicate the latter > symptom. It's really unclear how the former one could arise, because > nothing that vacuum.sql does would change xmin of the rows in pg_am. It probably changes the *relfilenode* of pg_am, because it runs VACUUM FULL on that catalog. Perhaps some backend sees the old relfilenode value and tries to a heap scan, interpreting the now-truncated file as empty? -- 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
