Lock Modes (Documentation)
От | Thomas F. O'Connell |
---|---|
Тема | Lock Modes (Documentation) |
Дата | |
Msg-id | 8BA7A07C-FE35-462D-84E6-BA188F318985@sitening.com обсуждение исходный текст |
Ответы |
Re: Lock Modes (Documentation)
|
Список | pgsql-general |
I thought about posting to pgsql-docs, but since this might require comment from developers, I thought -general might be a better starting point. Anyway, I've occasionally run into monitoring situations where it would be immediately helpful to know the built-in SQL statements that generate given table-lock modes. For instance, doesn't UPDATE implicitly mean that an ACCESS SHARE lock will be taken if there are foreign keys involved (at least in versions prior to 8.1)? Are there any other scenarios where a given SQL command might take a lock of one of these forms as a result of what it does under the hood? Maybe UPDATE is the only one since it's implicitly a SELECT, DELETE, and INSERT all rolled into one. I'd love to see 12.3 <http://www.postgresql.org/docs/8.0/static/ explicit-locking.html> document this more thoroughly, but I don't know enough about the underlying locking requirements of each step of each SQL command to know when locks might implicitly be acquired. Even if UPDATE is the only special case, it seems like it'd be worth mentioning. -- Thomas F. O'Connell Database Architecture and Programming Co-Founder Sitening, LLC http://www.sitening.com/ 110 30th Avenue North, Suite 6 Nashville, TN 37203-6320 615-469-5150 615-469-5151 (fax)
В списке pgsql-general по дате отправления: