| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Paul Friedman <paul(dot)friedman(at)streetlightdata(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: LWLocks by LockManager slowing large DB |
| Date: | 2021-04-14 01:01:58 |
| Message-ID: | 20210414010158.2oljt7kn75ej3vau@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Hi,
On 2021-04-13 19:16:46 -0400, Tom Lane wrote:
> > Maybe the same thing we do with user tables, ie not give up the lock
> > when we close a toast rel? As long as the internal lock counters
> > are 64-bit, we'd not have to worry about overflowing them.
Well, I was assuming we'd not want to do that, but I am generally on
board with the concept (and think our early lock release in a bunch of
places is problematic).
> Like this? This passes check-world, modulo the one very-unsurprising
> regression test change. I've not tried to do any performance testing.
I wonder if there's a realistic chance it could create additional
deadlocks that don't exist right now?
Would it be a problem that we'd still release the locks on catalog
tables early, but not on its toast table?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-04-14 03:04:50 | Re: LWLocks by LockManager slowing large DB |
| Previous Message | Tom Lane | 2021-04-13 23:16:46 | Re: LWLocks by LockManager slowing large DB |