Return-Path: pg_adm@postgres.berkeley.edu Received: by postgres.Berkeley.EDU (5.61/1.29) id AA01779; Thu, 22 Apr 93 05:15:52 -0700 Date: Thu, 22 Apr 93 05:15:52 -0700 Message-Id: <9304221215.AA01779@postgres.Berkeley.EDU> From: Gerry Stringer Subject: Re: incrementing counter To: postgres@postgres.berkeley.edu Sender: pg_adm@postgres.berkeley.edu Nat Howard writes:, > What I *really* want, though, is a way get atomically-incremented > values, so that neither transaction must time out: >>this seems to work better: >>begin >>replace tt_number (tt_number = tt_number.tt_number + 1) >>retrieve (tt_number.tt_number) >>/* other stuff */ >>end >> ... >> ... This is my solution as well ie. acquire `write locks' for all tables you may want to update at the start of any transaction. This is very artificial however, suppose you want to do an update conditionally on values you read from a table - you end up needing to do a dummy write to the table to lock it. Of course, this assumes that you know the granularity of locking is the whole table. IMHO doing this sort of code requires too much knowledge and fudging. Perhaps an answer is to have an optional exclusive read lock (like a write lock) or manual control of locking? gerry +--------------------------------+---------------------------------+ |Gerry Stringer |Phone: +44 954 780926 | |Cambridge Scanning Company Ltd |Fax: +44 954 789829 | |Saxon Way |UUCP : gerry@camscan.co.uk | |Bar Hill | gerry@camscan.uucp | |Cambridge CB3 8SL | | |United Kingdom | | +--------------------------------+---------------------------------+