Re: Avoid orphaned objects dependencies, take 3
От | Robert Haas |
---|---|
Тема | Re: Avoid orphaned objects dependencies, take 3 |
Дата | |
Msg-id | CA+TgmoaCJ5-Zx5R0uN+ah4EZU1SamY1PneaW5O617FsNKavmfw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Avoid orphaned objects dependencies, take 3 (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Avoid orphaned objects dependencies, take 3
|
Список | pgsql-hackers |
On Mon, May 19, 2025 at 1:02 PM Jeff Davis <pgsql@j-davis.com> wrote: > I'm not sure if you intended it this way, but using "clever" here > suggests that it's an unusual trick. But isn't that the kind of thing > heavyweight locks are for? > > FWIW, a lock while recording a dependency would not be surprising to > me. Assuming that heavyweight locks are the right approach, the locks > need to be taken somewhere. And expecting all the callers to get it > right seems error-prone. I agree with that, but I think that it may also be error-prone to assume that it's OK to acquire heavyweight locks on other catalog objects at any place in the code where we record a dependency. I will not be surprised at all if that turns out to have some negative consequences. For example, I think it might result in acquiring the locks on those other objects at a subtly wrong time (leading to race conditions) or acquiring two locks on the same object with different lock modes where we should really only acquire one. I'm all in favor of solving this problem using heavyweight locks, but I think that implicitly acquiring them as a side effect of recording dependencies feels too surprising. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: