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 A07D632A3C0 for ; Wed, 6 Oct 2004 21:36:49 +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 41867-05 for ; Wed, 6 Oct 2004 20:36:43 +0000 (GMT) Received: from web50004.mail.yahoo.com (web50004.mail.yahoo.com [206.190.38.19]) by svr1.postgresql.org (Postfix) with SMTP id 05C3932A39B for ; Wed, 6 Oct 2004 21:36:43 +0100 (BST) Message-ID: <20041006203642.19308.qmail@web50004.mail.yahoo.com> Received: from [69.65.137.210] by web50004.mail.yahoo.com via HTTP; Wed, 06 Oct 2004 15:36:42 CDT Date: Wed, 6 Oct 2004 15:36:42 -0500 (CDT) From: Jaime Casanova Subject: Table locks To: pgsql-sql@postgresql.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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/41 X-Sequence-Number: 19144 --- Tom Lane escribió: > Andreas Seltenreich writes: > > Jake Stride writes: > >> I thought of doing: > >> SELECT max(jobno) from jobs where companyid=1; > > > I think SELECT FOR UPDATE should work fine here. > > Nope; he'll get something like > > regression=# select max(unique1) from tenk1 for > update; > ERROR: SELECT FOR UPDATE is not allowed with > aggregate functions > > His best bet is probably > > BEGIN; > LOCK TABLE jobs; > SELECT max(jobno) from jobs where companyid=1; > INSERT INTO jobs ... > COMMIT; > > This is pretty horrid from a concurrency point of > view but I don't think > there's any other way to meet the "no gaps" > requirement. > > You could reduce the strength of the lock a bit, for > instance > LOCK TABLE jobs IN EXCLUSIVE MODE; > which would allow readers of the jobs table to > proceed concurrently, > but not writers. If you were willing to assume that > all inserters into > jobs are cooperating by explicitly obtaining the > correct lock, you > could reduce it to > LOCK TABLE jobs IN SHARE UPDATE EXCLUSIVE MODE; > which is the lowest self-conflicting table lock > type. This would allow > unrelated updates to the jobs table to proceed > concurrently too (though > not VACUUMs). See > > http://www.postgresql.org/docs/7.4/static/explicit-locking.html > > regards, tom lane > Hi, Talking about lock tables there is a way to do a select ... for update and then a update .. where current of ... I think it require a select for update in a cursor. Thanx in advance, Jaime Casanova _________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com