Lock and read next

Lists: pgsql-novice
From: "Girish Bajaj" <gbajaj(at)tietronix(dot)com>
To: <pgsql-novice(at)postgresql(dot)org>
Subject: Lock and read next
Date: 2003-09-03 21:56:30
Message-ID: 005701c37266$3b4ba630$7764a8c0@tietronix.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-novice

Is there a way if one transaction has locked a row in a table, the next
transaction does not get blocked while reading the same row, but moves on to
the next record in the table to read?

Example:

Transaction 1

Select * from table LIMIT 1 FOR UPDATE

--transaction takes 3 min to complete

Transaction 2

Select * from table LIMIT 1 FOR UPDATE

Here, transaction 2 blocks on the same record that transaction 1 has a write
lock on (for 3 min). Is there a way to tell transaction 2 to move on and get
the next writable record?

Thanks,

Girish


From: Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
To: PgSQL Novice ML <pgsql-novice(at)postgresql(dot)org>
Subject: Re: Lock and read next
Date: 2003-09-03 22:37:19
Message-ID: 1062628639.7342.437.camel@haggis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-novice

On Wed, 2003-09-03 at 16:56, Girish Bajaj wrote:
> Is there a way if one transaction has locked a row in a table, the
> next transaction does not get blocked while reading the same row, but
> moves on to the next record in the table to read?
>
> Example:
>
> Transaction 1
>
> Select * from table LIMIT 1 FOR UPDATE
>
> --transaction takes 3 min to complete

Why the heck do the transactions take 3 minutes??!!??!!

> Transaction 2
>
> Select * from table LIMIT 1 FOR UPDATE
>
> Here, transaction 2 blocks on the same record that transaction 1 has a
> write lock on (for 3 min). Is there a way to tell transaction 2 to
> move on and get the next writable record?

Does SQL even support that kind of semantics?

--
-----------------------------------------------------------------
Ron Johnson, Jr. ron(dot)l(dot)johnson(at)cox(dot)net
Jefferson, LA USA

"Man, I'm pretty. Hoo Hah!"
Johnny Bravo


From: "Girish Bajaj" <gbajaj(at)tietronix(dot)com>
To: <pgsql-novice(at)postgresql(dot)org>
Subject: Re: Lock and read next
Date: 2003-09-04 00:25:35
Message-ID: 006001c3727b$0ee3a650$7764a8c0@tietronix.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-novice

I don't know if sql supports this or not, but when I was using ms sql
server, it supports something called readpast lock hint.

My transactions are not really 3 min long. Its just a long running
transaction. And since multiple processes will be accessing the same table
(all do the same task), they should all be working on different tasks rather
than the same one. This is taken care of by the FOR UPDATE sql statement.
Process 2 should acquire a lock on another row somehow and not block.

Thanks,
Girish

-----Original Message-----
From: pgsql-novice-owner(at)postgresql(dot)org
[mailto:pgsql-novice-owner(at)postgresql(dot)org] On Behalf Of Ron Johnson
Sent: Wednesday, September 03, 2003 5:37 PM
To: PgSQL Novice ML
Subject: Re: [NOVICE] Lock and read next

On Wed, 2003-09-03 at 16:56, Girish Bajaj wrote:
> Is there a way if one transaction has locked a row in a table, the
> next transaction does not get blocked while reading the same row, but
> moves on to the next record in the table to read?
>
> Example:
>
> Transaction 1
>
> Select * from table LIMIT 1 FOR UPDATE
>
> --transaction takes 3 min to complete

Why the heck do the transactions take 3 minutes??!!??!!

> Transaction 2
>
> Select * from table LIMIT 1 FOR UPDATE
>
> Here, transaction 2 blocks on the same record that transaction 1 has a
> write lock on (for 3 min). Is there a way to tell transaction 2 to
> move on and get the next writable record?

Does SQL even support that kind of semantics?

--
-----------------------------------------------------------------
Ron Johnson, Jr. ron(dot)l(dot)johnson(at)cox(dot)net
Jefferson, LA USA

"Man, I'm pretty. Hoo Hah!"
Johnny Bravo

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match