I agree which is why I'm asking the question. In this case, I'm trying to
ensure that my inventory quantity is not changed by some other request as
the first one does a test of availability and then decrements that
availability.
After various responses, it looks like SELECT...FOR UPDATE does fit the bill
if I use it consistently for querying the records I'm interested in.
I'm no psql expert, so every day it's something new to add to my toolkit.
-a
-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org]On Behalf Of Tom Lane
Sent: Monday, December 30, 2002 16:17
To: Andy Kriger
Cc: Pgsql-General
Subject: Re: [GENERAL] lock table question
"Andy Kriger" <akriger@greaterthanone.com> writes:
> It doesn't lock the row from being read. I want to make sure the row
cannot
> be read until I have done my read and updated if necessary.
Why?
You're really swimming upstream against the notion of MVCC if you want
to prevent pure readers from proceeding while your update transaction
runs. Since you claim to be concerned about bottlenecks, I do not see
why you shouldn't embrace the MVCC worldview, rather than fighting it
tooth and nail.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
