Skip site navigation (1) Skip section navigation (2)

Re: row level locking

From: "Sibte Abbas" <sibtay(at)gmail(dot)com>
To: "Mark Steben" <msteben(at)autorevenue(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: row level locking
Date: 2007-07-20 18:54:55
Message-ID: bd6a35510707201154r62884d1cp106aa1c88d4f46ec@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-admin
On 7/20/07, Mark Steben <msteben(at)autorevenue(dot)com> wrote:
>
> Hi listers,
>
> I have a table that is accessed by only one transaction.  It has 1500 rows
> each time that it processes
>
> This transaction.  As soon as this transaction ends, it waits 10 seconds and
> starts again.
>
> It has another maximum 1500 rows loaded. .
>
>
>
> My question is this:  I believe a RowExclusive level lock is acquired 1500
> times during each transaction.

What type operations does the transaction performs on the table?

An exclusive row level lock is acquired only:

i) when a row is being updated, deleted or marked for deletion (Implicit lock)
ii) when SELECT FOR UPDATE query is executed on the table (to acquire
a share lock you can use SELECT FOR SHARE) (Explicit lock)

>
> Is this true?  Is there a way to disable RowExclusive locks and reduce
> overhead since only this transaction

Consider running postgresql in single user mode. This would eradicate
all the Interprocess communication overheads.

>
> Accesses this table.   I know there are ways to specify locking levels in
> other DBMSs. To page or table levels.
>

Postgresql handles page level locks implicitly, users do not have any
control over them.

regards,
-- 
Sibte Abbas
EnterpriseDB http://www.enterprisedb.com

In response to

pgsql-admin by date

Next:From: Jessica RichardDate: 2007-07-20 19:00:18
Subject: select a range of data
Previous:From: Mark StebenDate: 2007-07-20 18:19:36
Subject: row level locking

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group