Rural Hunter wrote:
> Kevin Grittner wrote:
>> Rural Hunter 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 f
hmmno 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
Rural Hunter 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
well, thanks. I checked the application and found there was a bug
causing many queries were updating the same row. However, those updates
are just single statement, no multi-statement transaction involved. So
I still have this question:
same statement A,B,C,D update same row. The start order is
Hi,
> > I dig another case more and found something interesting. it's actually
> > waiting for a lock of type transactionid. I ran the query below 3
>
> Normal. That's the kind of lock you are waiting for when some other
> transaction has touched the same rows for update that you are
> attemptin
Rural Hunter writes:
> yes, it's truncated. the full sql is like this:
> "update article set
> tm_update=$1,rply_cnt=$2,read_cnt=$3,tm_last_rply=$4 where
> title_hash=$5"
> the title_hash is unique.
>
> I dig another case more and found something interesting. it's actually
> waiting for a lock of
yes, it's truncated. the full sql is like this:
"update article set
tm_update=$1,rply_cnt=$2,read_cnt=$3,tm_last_rply=$4 where
title_hash=$5"
the title_hash is unique.
I dig another case more and found something interesting. it's actually
waiting for a lock of type transactionid. I ran the qu
Hi!
> I don't see a WHERE clause, so it looks like you're updating the
> whole table each time.
it's got a substr(pg_stat_activity.current_query,1,30) in it, so we shall
hardly see anything about the WHERE clause, but we'd really need to have
more info about it.
Bèrto
--
=
Rural Hunter wrote:
> I'm seeing connection hang issue these days. many concurrent
> connections are hanging on db. They basically do the same thing:
> update different rows in same table. The sql itself should run very
> fast as it's updating just one row based on an unique key.
> update arti
I'm seeing connection hang issue these days. many concurrent
connections are hanging on db. They basically do the same thing:
update different rows in same table. The sql itself should run very
fast as it's updating just one row based on an unique key. I though
it might b
10 matches
Mail list logo
