Обсуждение: acquiring row and page level locks

hi ,
coudl some one tell me how to acquire row-level and page level locks in
postgresql.
iam aware that table level locks can be acquired by the command:
"lock table *tablename* in *locktype* mode;
thanks

_________________________________________________________________
Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
using MSN Messenger http://entertainment.msn.com/imastar

On Thu, Aug 28, 2003 at 20:08:33 -0700,
  Jenny - <nat_lazy@hotmail.com> wrote:
> hi ,
> coudl some one tell me how to acquire row-level and page level locks in
> postgresql.
> iam aware that table level locks can be acquired by the command:
> "lock table *tablename* in *locktype* mode;

select for update will get you row level write locks. It won't block
normal selects.

>select for update will get you row level write locks. It won't block
>normal selects.
there are no row level read locks in postgresql right?
thanks
jenny

>From: Bruno Wolff III <bruno@wolff.to>
>To: Jenny - <nat_lazy@hotmail.com>
>CC: pgsql-general@postgresql.org
>Subject: Re: [GENERAL] acquiring row and page level locks
>Date: Thu, 28 Aug 2003 22:20:22 -0500
>
>On Thu, Aug 28, 2003 at 20:08:33 -0700,
>   Jenny - <nat_lazy@hotmail.com> wrote:
> > hi ,
> > coudl some one tell me how to acquire row-level and page level locks in
> > postgresql.
> > iam aware that table level locks can be acquired by the command:
> > "lock table *tablename* in *locktype* mode;
>
>select for update will get you row level write locks. It won't block
>normal selects.

_________________________________________________________________
Get MSN 8 and help protect your children with advanced parental controls.
http://join.msn.com/?page=features/parental

On Fri, 29 Aug 2003, Jenny - wrote:

> >select for update will get you row level write locks. It won't block
> >normal selects.
> there are no row level read locks in postgresql right?

Not currently.

My observations are completely subjective and without means of proof or raw data that I can throw around.

As a result of a sql statement that 7.4 knows how to optimize I have setup 7.4 on my redhat 9.x beta box (it installz, etc but segfaults on my gentoo box). 

I am sure some of what I a seeing relates to the fact that I have decided to switch to 2.6.beta3-mm1 on my redhat box.  With 7.4 I have seen some starvation issues when importing the database I use while working on the desktop. To be honest I am cool with that because it fits with my other observations.

I have not followed the 7.4 development (however I did follow for a few days the should 7.4 be 8.0 argument).

I have been reading the performance results and those involved with development's honest astonishment over the numbers. 

>From my observations I need to ask if it's possible that there has been a change in concurrency with 7.4.  When importing a database this is the first release where more then 1 of my cpu's or IO systems have been waiting on things.  It's been one of the reasons I have been a secret but never vocal advocate for a multi-threaded version of postgresql.

But everything I am seeing monitoring my system says more concurrency goes on with 7.4 then 7.3 and that alone (at least if done right) should almost certainly account for the benchmarks we have seen.

So... are my observations correct or possible as a means to explain the difference between 7.4 and 7.3?

Thanks, looking forward to this discussion,

Steven