From: Rural Hunter <ruralhunter@gmail.com>
To: Kevin Grittner <kevin.grittner@wicourts.gov>
Cc: Jerry Sievers <gsievers19@comcast.net>
Cc: pgsql-admin@postgresql.org
Cc: berto.d.sera@gmail.com
Subject: Re: lock problem
Date: Thu, 22 Dec 2011 09:44:42 +0800
Message-ID: <4EF28B8A.1060602@gmail.com> (raw)
In-Reply-To: <4EF1B04D0200002500043F4C@gw.wicourts.gov>
References: <4EF18A8A0200002500043F0A@gw.wicourts.gov>
<CAKwGa_-C0Gcp2PaNWS9_kq0nz7KfcbV8hb5XYmxzUyHNt6AF-w@mail.gmail.com>
<4EF1F027.507@gmail.com>
<87aa6m7xqz.fsf@comcast.net>
<CAKwGa__-7ncap5sji9x0=3g5V=Fv1cpZYGO5bKDHgxeT6z9rzg@mail.gmail.com>
<4EF20333.8020404@gmail.com>
<4EF1B04D0200002500043F4C@gw.wicourts.gov>
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@gmail.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
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: ruralhunter@gmail.com, kevin.grittner@wicourts.gov, gsievers19@comcast.net, berto.d.sera@gmail.com
Subject: Re: lock problem
In-Reply-To: <4EF28B8A.1060602@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox