Re: Improve heavyweight locks instead of building new lock managers?
От | Amit Langote |
---|---|
Тема | Re: Improve heavyweight locks instead of building new lock managers? |
Дата | |
Msg-id | CA+HiwqGmCnWKrhuGReG0giC1nA=Swoe_X09armrNTf0q50XD5Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Improve heavyweight locks instead of building new lock managers? (Andres Freund <andres@anarazel.de>) |
Список | 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 по дате отправления: