X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 2DE04329CAE for ; Sun, 3 Oct 2004 18:16:01 +0100 (BST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 07986-10 for ; Sun, 3 Oct 2004 17:15:51 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 46842329C83 for ; Sun, 3 Oct 2004 18:15:51 +0100 (BST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id i93HFpW2003319; Sun, 3 Oct 2004 13:15:51 -0400 (EDT) To: Dag Gullberg Cc: pgsql-sql@postgresql.org Subject: Re: Concurrency problem In-reply-to: <1096801131.5238.32.camel@hemma> References: <1096801131.5238.32.camel@hemma> Comments: In-reply-to Dag Gullberg message dated "03 Oct 2004 12:58:52 +0200" Date: Sun, 03 Oct 2004 13:15:50 -0400 Message-ID: <3318.1096823750@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200410/15 X-Sequence-Number: 19118 Dag Gullberg writes: > Warning: pg_query(): Query failed: ERROR: tuple concurrently updated > CONTEXT: PL/pgSQL function "get_rights" line 5 at SQL statement in > /home/site/PHP/db_func.php on line 301 > Code of get_rights: > GRANT SELECT ON c.users TO > adm,w3; > SELECT rights INTO result > FROM c.users > WHERE usr_id=uid; > REVOKE ALL ON c.users FROM w3,adm; > RETURN result; Do you have a bunch of clients doing this in parallel? If so, the problem is probably coming from two instances of the function trying to update the catalog entry for c.users at the same time. The approach is fundamentally broken anyhow, because there is nothing stopping client 2 from revoking the rights in between client 1 doing his GRANT and his SELECT. The right way to do what you seem to want (allow only this function to access the table) is not to flap the rights settings back and forth like that. Grant SELECT rights to a specific userid and make the function be owned by that userid and be labeled SECURITY DEFINER. regards, tom lane