Re: Overcoming SELECT ... FOR UPDATE permission restrictions
| От | Alexander Lakhin |
|---|---|
| Тема | Re: Overcoming SELECT ... FOR UPDATE permission restrictions |
| Дата | |
| Msg-id | 667c0861-3375-a537-ae09-5e8b293ebf50@gmail.com обсуждение исходный текст |
| Ответ на | Re: Overcoming SELECT ... FOR UPDATE permission restrictions (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Overcoming SELECT ... FOR UPDATE permission restrictions
|
| Список | pgsql-hackers |
13.04.2018 18:55, Tom Lane wrote: > Although this is arguably a security bug, I'm not sure we should > back-patch it. The consequences seem relatively minor, and the > behavioral change carries a significant risk of breaking applications > that worked as-intended up to now. Thoughts? The worst scenario (with the current system views) I could think of is: user=> CREATE VIEW pgg AS SELECT * FROM pg_group; BEGIN TRANSACTION; SELECT * FROM pgg FOR UPDATE; SELECT pg_sleep(60); ROLLBACK; and the parallel operation: admin=> DROP ROLE testrole; hangs for one minute. But admin can observer the locks and kill the offending backend so it's hardly a critical issue.
В списке pgsql-hackers по дате отправления: