Re: [COMMITTERS] pgsql: Fix LOCK TABLE to eliminate the race condition that could make it
В списке pgsql-hackers по дате отправления:
| От | Simon Riggs |
|---|---|
| Тема | Re: [COMMITTERS] pgsql: Fix LOCK TABLE to eliminate the race condition that could make it |
| Дата | |
| Msg-id | 1242161438.3843.334.camel@ebony.2ndQuadrant обсуждение исходный текст |
| Ответы |
Re: [COMMITTERS] pgsql: Fix LOCK TABLE to eliminate the race condition that could make it
|
| Список | pgsql-hackers |
On Tue, 2009-05-12 at 16:43 +0000, Tom Lane wrote: > Fix LOCK TABLE to eliminate the race condition that could make it give weird > errors when tables are concurrently dropped. To do this we must take lock > on each relation before we check its privileges. The old code was trying > to do that the other way around, which is a bit pointless when there are lots > of other commands that lock relations before checking privileges. I did keep > it checking each relation's privilege before locking the next relation, which > is a detail that ALTER TABLE isn't too picky about. If we're going to require cascaded permissions like this, would it make sense to make GRANT cascade down the inheritance tree also? -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера