Re: Strange locking choices in pg_shdepend.c
От | Alvaro Herrera |
---|---|
Тема | Re: Strange locking choices in pg_shdepend.c |
Дата | |
Msg-id | 20080123161758.GK4815@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Strange locking choices in pg_shdepend.c (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-hackers |
Alvaro Herrera wrote: > Hmm, unless revoking privileges concurrently, for two different users on > the same object could cause a problem? I don't see us grabbing a lock > on the object itself -- does this matter? I tried a simple test: a process in a loop calling GRANT and REVOKE on random users on a given table, and another process calling DROP OWNED BY another set of users. Prepare the test: psql -c "create table foo()" for i in `seq 0 100`; do psql -c "create user u$i"; done for i in `seq 0 100`; do psql -c "create user v$i"; done for i in `seq 0 100`; do psql -c "grant select on table foo to u$i"; done Then, on one terminal while true do r=$((RANDOM * 100 / 32764)) s=$((RANDOM * 100 / 32764)) psql -c "grant select on table foo to v$r" psql -c "revoke selecton table foo from v$s" done And another terminal for i in `seq 1 100`; do psql -c "drop owned by u$i"; done I get a lot of ERREUR: tuple concurrently updated So, yeah, I think our GRANT/REVOKE code has a race condition, which probably isn't very critical at all but it's still there. -- Alvaro Herrera Valdivia, Chile Geotag: -39,815 -73,257 "God is real, unless declared as int"
В списке pgsql-hackers по дате отправления: