[ADMIN] Frequent 'deadlock detected' in 7.4 ... or just my bad code?
G'day ...
I've got a script that runs on all the servers that dump's IP traffic
data to a 7.4 database ... they all run at the same time, but I'm starting
to get the following on a reasonably regular basis:
ERROR: deadlock detected at /usr/local/abin/ipaudit2ams.pl line 175.
The code that is causing it, from the times I've been able to catch it,
is a simple update to the same table:
$upd->execute( $traffic{$company_id}{$ip_id}{$port}, $company_id, $ip_id, $date
) || die $upd->errstr;
Now, the scripts are wrap'd in a BEGIN/END ... if a file fails to be
loaded, I want the whole thing to rollback ... the deadlock itself, I'm
presuming, is because two servers are trying to update the same
$ip_id/$port/$company_id record, at the same time ...
Now, reading the DEADLOCKS section at:
http://www.postgresql.org/docs/7.4/static/explicit-locking.html
This is to be expected ... but, other then breaking the transaction
itself into smaller chunks, or staggering the scripts run times ... is
there something I'm overlooking to eliminate this? I could increase the
deadlock timeout, as an option as well ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [ADMIN] Frequent 'deadlock detected' in 7.4 ... or just my bad code?
"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > Now, the scripts are wrap'd in a BEGIN/END ... if a file fails to be > loaded, I want the whole thing to rollback ... the deadlock itself, I'm > presuming, is because two servers are trying to update the same > $ip_id/$port/$company_id record, at the same time ... Actually, the problem is more likely that two servers try to update two different rows in opposite orders. It's not possible to deadlock when only one lock is involved. You could work around this by ensuring that all sessions update rows in a consistent order; for instance, at the beginning of a transaction sort your intended updates by primary key and then apply in that order. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [ADMIN] Frequent 'deadlock detected' in 7.4 ... or just my bad code?
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> D'oh ... just tested my assumption, it was wrong ... *sigh* okay, back
> to the drawing board on the code ...
Can't you just change
>> foreach $company_id ( keys %traffic ) {
to
>> foreach $company_id ( sort keys %traffic ) {
etc.
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
