| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: Strange locking choices in pg_shdepend.c |
| Date: | 2008-01-23 16:17:58 |
| Message-ID: | 20080123161758.GK4815@alvh.no-ip.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 select on 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"
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gokulakannan Somasundaram | 2008-01-23 16:28:35 | Re: [HACKERS] Including Snapshot Info with Indexes |
| Previous Message | Gokulakannan Somasundaram | 2008-01-23 15:58:48 | Re: [HACKERS] Including Snapshot Info with Indexes |