Horton

Re: Improve heavyweight locks instead of building new lock managers?

Amit Langote <amitlangote09@gmail.com>

View thread View on postgr.es
From: Amit Langote <amitlangote09@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael@paquier.xyz>, Mithun Cy <mithun.cy@enterprisedb.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, Thomas Munro <thomas.munro@gmail.com>
Date: 2020-02-20T06:15:42Z
Lists: 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

Commits

  1. Remove SHM_QUEUE

  2. Use dlists instead of SHM_QUEUE for predicate locking

  3. Use dlists instead of SHM_QUEUE for syncrep queue

  4. Add detached node functions to ilist

  5. Use dlist/dclist instead of PROC_QUEUE / SHM_QUEUE for heavyweight locks