Re: deadlock problem in Ad serving..

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ron Mayer <ron(at)intervideo(dot)com>
Cc: Bhuvan A <bhuvansql(at)myrealbox(dot)com>, pgsql-admin(at)postgresql(dot)org
Subject: Re: deadlock problem in Ad serving..
Date: 2003-01-20 20:20:12
Message-ID: 15369.1043094012@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Ron Mayer <ron(at)intervideo(dot)com> writes:
> Is it true that the problem happens when updates are done
> in a different order by two transactions like this:

> trans.1: "update banner_stats set imp=imp+1 where uniqid=4330"
> trans.2: "update banner_stats set imp=imp+1 where uniqid=10"
> trans.1: "update banner_stats set imp=imp+1 where uniqid=10"
> trans.2: "update banner_stats set imp=imp+1 where uniqid=4330"

Yeah, I would assume that that's the problem.

> If so, then could the problem be avoided if in his application
> logic he always did the updates in the same order? ... I.e. Make
> sure the each transaction does the updates in the same order by
> sorting his updates based on uniqid in the client?

If I understood correctly, he's tracking webpage hits; so the updates
are going to correspond to the sequence in which visitors move to
different webpages. I don't think he can force a particular order
(and if he could, there'd be little need for the per-page counts
anyway). I suppose he could hold all the updates in a temp table
and apply them in a sorted order at end of transaction, but that seems
like a pain.

I would suggest using a separate transaction for each webpage visited.
Holding a transaction open across multiple page traversals is widely
considered bad news for a number of reasons, not only this one.

regards, tom lane

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Ron Mayer 2003-01-20 21:31:34 Re: deadlock problem in Ad serving..
Previous Message Ron Mayer 2003-01-20 17:58:10 Re: deadlock problem in Ad serving..