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
于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.
In response to
pgsql-admin by date
|Next:||From: Kevin Grittner||Date: 2011-12-22 03:26:26|
|Subject: Re: lock problem|
|Previous:||From: Craig James||Date: 2011-12-22 00:33:37|
|Subject: Re: Can't Insert from Staging Table to Production Table|