You can select "for update", so you ensure that the rows are locked for
your current transaction's use exclusively. If the rows in question had
been modified by another ongoing transaction, then the select will get
blocked until the other transaction is finished.
Cheers,
Ezequiel Tolnay
[EMAIL
On Mon, May 16, 2005 at 17:36:21 -0400,
Joel Fradkin <[EMAIL PROTECTED]> wrote:
> I was using SET TRANSACTION ISOLATION LEVEL SERIALIZABLE in MSSQL.
>
>
>
> Is there something similar in postgres to ensure its not in the middle of
> being updated?
Postgres also has SET TRANSACTION ISOLATION
I actually had the same thought (a counter table, I might be able to add
fields to the location table, but we have several applications case is just
an example). I agree that is probably the safest way and it also fixes
another issue I have been having when a user wants to transfer a case to
anothe
Joel Fradkin wrote:
I was using SET TRANSACTION ISOLATION LEVEL SERIALIZABLE in MSSQL.
Is there something similar in postgres to ensure its not in the middle of
being updated?
Yep - see the SQL COMMANDS reference section under SET TRANSACTION ...
You could use LOCK TABLE too.
See Chapter 12 - Concu
