| From: | Michael Fuhr <mike(at)fuhr(dot)org> |
|---|---|
| To: | Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> |
| Cc: | Carlos Benkendorf <carlosbenkendorf(at)yahoo(dot)com(dot)br>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Row level locking |
| Date: | 2005-10-12 15:29:42 |
| Message-ID: | 20051012152942.GA9201@winnie.fuhr.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, Oct 12, 2005 at 09:30:50PM +0800, Lincoln Yeoh wrote:
> will "lock sometable nowait" help?
>
> http://developer.postgresql.org/docs/postgres/sql-lock.html
>
> If it fails, something is in progress.
And if it succeeds then it might hurt the performance of concurrent
transactions, depending on which lock mode you use. Using SELECT
FOR UPDATE with a statement timeout might have less impact if you
only need to work with certain rows, and 8.1 will have SELECT FOR
{ UPDATE | SHARE } [ NOWAIT ].
Carlos, you said the applications were doing only inserts. Is that
right? Have you investigated what's causing the blocking? Do the
rows you're inserting have foreign key references? Let's find out
what the problem is before suggesting how to solve it.
--
Michael Fuhr
| From | Date | Subject | |
|---|---|---|---|
| Next Message | codeWarrior | 2005-10-12 15:39:09 | Re: user privilages for executing pg_autovacuum? |
| Previous Message | Larry Rosenman | 2005-10-12 15:28:46 | Re: Cannot compile on Slackware 10.2 |