Re: Improve heavyweight locks instead of building new lock managers? - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Improve heavyweight locks instead of building new lock managers?
Date
Msg-id CA+HiwqGmCnWKrhuGReG0giC1nA=Swoe_X09armrNTf0q50XD5Q@mail.gmail.com
Whole thread Raw
In response to Re: Improve heavyweight locks instead of building new lock managers?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi Andres,

On Thu, Feb 20, 2020 at 1:14 PM Andres Freund <andres@anarazel.de> wrote:
> Here's a *draft* patch series for removing all use of SHM_QUEUE, and
> subsequently removing SHM_QUEUE. There's a fair bit of polish needed,
> but I do think it makes the code considerably easier to read
> (particularly for predicate.c). The diffstat is nice too:
>
> 0005: Remove now unused SHMQueue*.
> 0006: Remove PROC_QUEUE.size.

Maybe you're aware, but there still seem to be places using it.  In
LOCK_DEBUG build:

lock.c: In function ‘LOCK_PRINT’:
lock.c:320:20: error: ‘PROC_QUEUE’ {aka ‘const struct PROC_QUEUE’} has
no member named ‘size’
     lock->waitProcs.size,

lock.c: In function ‘DumpLocks’:
lock.c:3906:2: error: unknown type name ‘SHM_QUEUE’; did you mean ‘SI_QUEUE’?

Fwiw, I for one, am all for removing specialized data structures when
more widely used data structures will do, especially if that
specialization is no longer relevant.

Thanks,
Amit



pgsql-hackers by date:

Previous
From: Adam Lee
Date:
Subject: Re: Memory-Bounded Hash Aggregation
Next
From: Hubert Zhang
Date:
Subject: Re: Print physical file path when checksum check fails