Re: lock table question
От | Andy Kriger |
---|---|
Тема | Re: lock table question |
Дата | |
Msg-id | OJEFIHHAALOBKKJEOMBDCENECNAA.akriger@greaterthanone.com обсуждение исходный текст |
Ответ на | Re: lock table question (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: lock table question
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: