From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Something is rotten in the state of Denmark... |
Date: | 2015-04-02 18:40:03 |
Message-ID: | 18862.1428000003@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Apr 2, 2015 at 12:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-04-02 18:43:27 | Re: Resetting crash time of background worker |
Previous Message | Robert Haas | 2015-04-02 18:30:30 | Re: Fix pgbench --progress report under (very) low rate |