Re: Something is rotten in the state of Denmark... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Something is rotten in the state of Denmark...
Date
Msg-id 18862.1428000003@sss.pgh.pa.us
Whole thread Raw
In response to Re: Something is rotten in the state of Denmark...  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Something is rotten in the state of Denmark...
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Apr 2, 2015 at 12:54 PM, Tom Lane <tgl@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.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Fix pgbench --progress report under (very) low rate
Next
From: Robert Haas
Date:
Subject: Re: Resetting crash time of background worker