From: | Ron Mayer <ron(at)intervideo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 17:58:10 |
Message-ID: | Pine.LNX.4.33.0301200949540.13721-100000@ron |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Mon, 20 Jan 2003, Tom Lane wrote:
>
> Bhuvan A <bhuvansql(at)myrealbox(dot)com> writes:
> >> Error:...deadlock detected...
> > ... You can overcome this by locking the table in share row
> > exclusive mode also...
>
> ...use shorter transactions (one per page, not one per several pages).
Hmm... with his query:
"update banner_stats set imp=imp+1 where uniqid=4330"
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"
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?
Ron
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-01-20 20:20:12 | Re: deadlock problem in Ad serving.. |
Previous Message | Christian Brink | 2003-01-20 17:48:33 | Re: deadlock problem in Ad serving.. |