On 05/30/2011 10:04 PM, Sebastian Böhm wrote:
Acquired by CREATE INDEX (without CONCURRENTLY).
so where the "ShareLock" is acquired? I don't create an index here.
There's some confusing historical terminology involved here, I'm afraid.
The documentation you referred to talks about table-
2009/3/19 Alvaro Herrera :
> Milos Findura wrote:
>> hi,
>> I found a deadlock on 2 queries, DELETE and REINDEX TABLE
>
> What version is this?
>
8.3
Milos is my colleague
regards
Pavel Stehule
>
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> PostgreSQL R
Milos Findura wrote:
> hi,
> I found a deadlock on 2 queries, DELETE and REINDEX TABLE
What version is this?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-general mailing l
Not so,
statements have diffrent pid. Delete is called in application, bud
REINDEX is
called via some cron admin script.
t.
On Thursday 19 of March 2009 13:35:03 Tom Lane wrote:
> Milos Findura writes:
> > where can be problem?
>
> Presumably, one statement or the other is inside a tr
Milos Findura writes:
> where can be problem?
Presumably, one statement or the other is inside a transaction that
already had a lower-grade lock on the target table.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
If the deadlocks occur because different transactions actually try to
update the same rows concurrently, then this is an appropriate solution.
However I wonder if Gavin is getting bitten by foreign key deadlocks.
Is there any foreign key reference from the stats table to other tables?
Tom,
The
Csaba Nagy <[EMAIL PROTECTED]> writes:
>> Can you explain why sorting by ID would make a difference as I don't
>> understand why what you are suggesting should make a difference?
>
> Because I guess id is your primary key, and that would make your
> transactions always update the same rows in the
Because I guess id is your primary key, and that would make your
transactions always update the same rows in the same order. It really
doesn't matter if you have other criteria in the where clause, the
issuing order of the statements is the problem.
Deadlock will occur if 2 concurrent transactions
Hi Csaba,
I am not ordering them by ID as in reality the where condition is more
complex than in my example
UPDATE stats SET click_count = click_count+1 WHERE month = '06' AND year
= '2005' AND type = 'a' AND id = '123' AND count_type = 'b'";
Can you explain why sorting by ID would make a d
Gavin,
Are you ordering the updates by id inside one transaction ? You should
order the execution of the statements by id inside a transaction, and
the deadlocks should go away.
HTH,
Csaba.
On Wed, 2005-06-15 at 13:10, Gavin Love wrote:
> I am getting a number of deadlock errors in my log files
10 matches
Mail list logo
