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

Re: lock problem

From: Rural Hunter <ruralhunter(at)gmail(dot)com>
To: Kevin Grittner <kevin(dot)grittner(at)wicourts(dot)gov>
Cc: Jerry Sievers <gsievers19(at)comcast(dot)net>, pgsql-admin(at)postgresql(dot)org, berto(dot)d(dot)sera(at)gmail(dot)com
Subject: Re: lock problem
Date: 2011-12-22 01:44:42
Message-ID: 4EF28B8A.1060602@gmail.com (view raw or flat)
Thread:
Lists: pgsql-admin
hmm....no I didn't do anything. is the lock priority decided by OS not 
the DB? I'm confused here. B/C/D started several mins later than A here 
while the update statement takes no more than 1 second. of coz there 
are hundreds of connections trying to acquire the lock during that 
time.

于2011年12月22日 0:09:17,Kevin Grittner写到:
> Rural Hunter<ruralhunter(at)gmail(dot)com>  wrote:
>
>> I still have this question:
>> same statement A,B,C,D update same row. The start order is
>> A->B->C-D.  From what I've gotten, B/C/D got the lock before A.
>> Why did that happen?
>
> Did you do anything to prevent it from happening?  If not, the OS
> scheduler is going to give time to one process or another in a
> fairly unpredictable way.
>
> -Kevin
>



In response to

pgsql-admin by date

Next:From: Kevin GrittnerDate: 2011-12-22 03:26:26
Subject: Re: lock problem
Previous:From: Craig JamesDate: 2011-12-22 00:33:37
Subject: Re: Can't Insert from Staging Table to Production Table

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