Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Дата
Msg-id CA+TgmobDF5CnCLhvO1LdzE6+5i04ePbjbiUeyfH-bKdK-3oxwg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager  (Mahendra Singh Thalor <mahi6run@gmail.com>)
Ответы Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Thu, Mar 5, 2020 at 2:18 PM Mahendra Singh Thalor <mahi6run@gmail.com> wrote:
> Here, attaching new patch set for review.

I was kind of assuming that the way this would work is that it would
set a flag or increment a counter or something when we acquire a
relation extension lock, and then reverse the process when we release
it. Then the Assert could just check the flag. Walking the whole
LOCALLOCK table is expensive.

Also, spelling counts. This patch features "extention" multiple times,
plus also "hask," "beloging," "belog," and "whle", which is an awful
lot of typos for a 70-line patch. If you are using macOS, try opening
the patch in TextEdit. If you are inventing a new function name, spell
the words you include the same way they are spelled elsewhere.

Even aside from the typo, AssertAnyExtentionLockHeadByMe() is not a
very good function name. It sounds like it's asserting that we hold an
extension lock, rather than that we don't, and also, that's not
exactly what it checks anyway, because there's this special case for
when we're acquiring a relation extension lock we already hold.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Antonin Houska
Дата:
Сообщение: Re: Atomics in localbuf.c
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Retiring support for pre-7.3 FK constraint triggers