acquiring row and page level locks

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