Robert Haas writes:
> On Mon, Nov 14, 2016 at 4:42 PM, Tom Lane wrote:
>> ... I'm inclined to hold my nose and stick a call into step (1) of the
>> main loop instead.
> Seems like a good idea.
>> Also, wherever we end up putting those calls, is it worth providing a
>> variant invalidation funct
On Mon, Nov 14, 2016 at 4:42 PM, Tom Lane wrote:
>> No, I'm not at all proposing to assume that. But I may be willing to
>> assume that "we don't hold a CatalogSnapshot between Bind and Execute
>> unless we're also holding a transaction snapshot". I need to do a bit
>> more research to see if th
I wrote:
> Robert Haas writes:
>> I assume you're going to back-patch this, and the consequences of
>> failing to reset it before going idle could easily be vastly worse
>> than the problem you're trying to fix. So I'd rather not make
>> assumptions like "the client will probably never sleep betw
Robert Haas writes:
> I assume you're going to back-patch this, and the consequences of
> failing to reset it before going idle could easily be vastly worse
> than the problem you're trying to fix. So I'd rather not make
> assumptions like "the client will probably never sleep between Bind
> and
On Mon, Nov 14, 2016 at 10:17 AM, Tom Lane wrote:
>> I think the really important thing is that we don't leave xmin set
>> when the backend is idle.
>
> Agreed. I did some stats-gathering on this over the weekend, seeing how
> often the various situations occur during the core regression tests.
>
Robert Haas writes:
> On Fri, Nov 11, 2016 at 3:15 PM, Tom Lane wrote:
>> The basic problem here, therefore, is that SnapshotResetXmin isn't aware
>> that GetCatalogSnapshot is keeping a possibly-unregistered snapshot in
>> its hip pocket. That has to change. We could either treat the saved
>>
On Fri, Nov 11, 2016 at 3:15 PM, Tom Lane wrote:
> So this has pretty much been broken since we put in MVCC snapshots for
> catalog searches. The problem would be masked when inside a transaction
> that has already got a transaction snapshot, but whenever we don't have
> one already, our catalog
I wrote:
> So it's happening when RelationCacheInitializePhase3 is trying to replace
> a fake pg_class row for pg_proc (made by formrdesc) with the real one.
> That's even odder, because that's late enough that this should be a pretty
> ordinary catalog lookup. Now I wonder if it's possible that t
I wrote:
> A quick look through the sources confirms that this error implies that
> SearchSysCache on the RELOID cache must have failed to find a tuple for
> pg_proc --- there are many occurrences of this text, but they all are
> reporting that. Which absolutely should not be happening now that we
I noticed that buildfarm member piculet fell over this afternoon:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=piculet&dt=2016-11-10%2020%3A10%3A02
with this interesting failure during startup of the "collate" test:
psql: FATAL: cache lookup failed for relation 1255
1255 is pg_proc, and
10 matches
Mail list logo
