Skip site navigation (1) Skip section navigation (2)

Re: Strange locking choices in pg_shdepend.c

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 (view raw, whole thread or download thread mbox)
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"

In response to

pgsql-hackers by date

Next:From: Gokulakannan SomasundaramDate: 2008-01-23 16:28:35
Subject: Re: [HACKERS] Including Snapshot Info with Indexes
Previous:From: Gokulakannan SomasundaramDate: 2008-01-23 15:58:48
Subject: Re: [HACKERS] Including Snapshot Info with Indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group