On Mon, Aug 15, 2005 at 11:30:32PM +0200, Andreas Seltenreich wrote:
>
> This would be one possibility. If you don't want your application to
> deal with transactions being aborted because of non-serializable
> transactions, you could alternatively use explicit locking (SELECT ...
> FOR UPDATE) combined with the Read Committed isolation level (the
> default).
SELECT FOR UPDATE locks just the rows that are selected, right? If I
understand correctly, that would not work for my case because I'm
updating different rows than I'm selecting.
My tables are small, so I'm thinking of just manually updating all the
rows in sequence to adjust the order when needed -- to make things a
bit more simple. But it is a problem that I am curious about how best
to solve in a scalable way.
Thanks very much for your feedback.
--
Bill Moseley
moseley@xxxxxxxx
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
