Re: Improve LWLock tranche name visibility across backends
От | Nathan Bossart |
---|---|
Тема | Re: Improve LWLock tranche name visibility across backends |
Дата | |
Msg-id | aJuaoouYv8l8f0PS@nathan обсуждение исходный текст |
Ответ на | Re: Improve LWLock tranche name visibility across backends (Sami Imseih <samimseih@gmail.com>) |
Ответы |
Re: Improve LWLock tranche name visibility across backends
|
Список | pgsql-hackers |
I haven't followed the latest discussion, but I took a look at the patch. + It is possible to use a <literal>tranche_id</literal> that was not retrieved + using <function>LWLockNewTrancheId</function>, but this is not recommended. + The ID may clash with an already registered tranche name, or the specified + name may not be found. In such cases, looking up the name will return a generic + "extension" tranche name. Is there any reason to continue allowing this? For example, maybe we could ERROR if LWLockInitialize()/GetLWTrancheName() are given a tranche_id greater than the number allocated. I guess I'm not following why we should gracefully handle these kinds of coding errors, especially when they result in unhelpful behavior like an "extension" tranche. +#else +elog(ERROR, "injection points not supported"); +#endif This causes compilation to fail when injection points are not enabled. I haven't combed through the patch character-by-character, but upon a read-through, the general shape looks reasonable to me. As a general note, I'd suggest adding more commentary throughout and finding opportunities to simplify and/or clean up the code as much as possible. -- nathan
В списке pgsql-hackers по дате отправления: