On Wed, Aug 28, 2019 at 3:05 AM Tom Lane wrote:
> I'd vote for back-patching to 10. Even if there is in fact no deadlock
> hazard, you've clearly demonstrated a significant performance hit that
> we're taking for basically no reason.
Done.
The second symptom reported in my first email looked li
Thomas Munro writes:
> On Tue, Aug 27, 2019 at 1:54 PM Tom Lane wrote:
>> +1. That fix is also back-patchable, which adding fields to relcache
>> entries would not be.
> There is a fly in the ointment: REL9_6_STABLE's copy of
> RelationHasUnloggedIndex() is hardcoded to return true for hash
> i
On Tue, Aug 27, 2019 at 1:54 PM Tom Lane wrote:
> Thomas Munro writes:
> > OK I started writing a patch and realised there were a few ugly
> > problems that I was about to report here... but now I wonder if, based
> > on the comment for RelationHasUnloggedIndex(), we shouldn't just nuke
> > all t
Thomas Munro writes:
> OK I started writing a patch and realised there were a few ugly
> problems that I was about to report here... but now I wonder if, based
> on the comment for RelationHasUnloggedIndex(), we shouldn't just nuke
> all this code. We don't actually support unlogged indexes on
>
On Tue, Aug 27, 2019 at 10:59 AM Tom Lane wrote:
> > At first glance it seems
> > like we need to capture PageGetLSN(page) while we have the lock, and
> > then later pass that into TestForOldSnapshot() instead of the page.
> > I'll look into that and write a patch, probably in a day or two.
>
> Hm
Thomas Munro writes:
> On Tue, Aug 27, 2019 at 9:28 AM Tom Lane wrote:
>> It is hard to express what a bad idea it is to be asking for complex
>> catalog searches while holding a buffer lock. We could easily get
>> into undetectable deadlocks that way, for example. We need to refactor
>> these
On Tue, Aug 27, 2019 at 9:28 AM Tom Lane wrote:
> I agree that this code is absolutely horrid as it stands. However,
> it doesn't look to me like caching RelationHasUnloggedIndex is quite
> enough to fix it. The other problem is that the calls in question
> seem to be mostly in TestForOldSnapsho
Thomas Munro writes:
> On my laptop, all prewarmed, no concurrency, the mere existence of 10
> brin indexes causes a sequential scan to take ~5% longer and an
> uncorrelated index scan to take ~45% longer (correlated index scans
> don't suffer). Here's a draft patch for v13 that fixes that proble
On Fri, Jun 21, 2019 at 1:21 AM Thomas Munro wrote:
> I ran into someone with a system where big queries scanning 8GB+ of
> all-in-cache data took consistently ~2.5x longer on a primary server
> than on a replica. Both servers had concurrent activity on them but
> plenty of spare capacity and sim
