Bug#614968: has now impacted testing

2011-03-06 Thread James Bottomley 
On Sat, 2011-03-05 at 10:34 -0600, James Bottomley wrote:
 If I remove the transactions and just do a straight delete, everything
 works (at least in my test environment; I'll try it on the real program
 tonight).  There's actually no real reason for the deletes to be done
 transactionally.  Even if we get a crash, we don't care whether all the
 keys or none are deleted ... if we get partial deletion, the next
 cleanup will get the rest.

OK, so confirmed last night that the cleanup ran correctly without the
transactional logic and that postgrey didn't die:

Mar  6 02:17:23 bedivere postgrey[32282]: cleaning main database finished. 
before: 9349, after: 4484
Mar  6 02:17:24 bedivere postgrey[32282]: cleaning clients database finished. 
before: 2844, after: 2336

The patch below is what I'm running.

James

---

--- /usr/sbin/postgrey.orig 2011-01-11 13:15:43.0 -0800
+++ /usr/sbin/postgrey  2011-03-05 08:40:02.0 -0800
@@ -275,11 +275,7 @@
 $nr_keys_after++;
 }
 }
-my $db_obj = $self-{postgrey}{db_obj};
-my $txn = $db_env-txn_begin();
-$db_obj-Txn($txn);
 for my $key (@old_keys) { delete $db-{$key}; }
-$txn-txn_commit();
 
 $self-mylog(1, cleaning main database finished. before: 
$nr_keys_before, after: $nr_keys_after);
 
@@ -299,11 +295,7 @@
 $nr_keys_after++;
 }
 }
-my $db_cawl_obj = $self-{postgrey}{db_cawl_obj};
-$txn = $db_env-txn_begin();
-$db_cawl_obj-Txn($txn);
 for my $key (@old_keys_cawl) { delete $cawl_db-{$key}; }
-$txn-txn_commit();
 
 $self-mylog(1, cleaning clients database finished. before: 
$nr_keys_before, after: $nr_keys_after);
 }





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#614968: has now impacted testing

2011-03-06 Thread Antonio Radici 
On Sun, Mar 06, 2011 at 07:20:20AM -0600, James Bottomley wrote:
 The patch below is what I'm running.

Hi James,
thanks for the patch, I will integrate it and release later on today,
let's see if it improves the situation for Joey and anyone else who is
experiencing the problem.

Cheers
Antonio



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#614968: has now impacted testing

2011-03-05 Thread James Bottomley 
On Fri, 2011-03-04 at 15:06 -0400, Joey Hess wrote:
 James Bottomley wrote:
  I picked this up on a recent testing upgrade (last Saturday).  My
  postgrey process is now dying every night as well (I've set up a harness
  to restart it, but it's not ideal).
  
  Following what happened in #441069 I tried
  
  db5.1_recover -h /var/lib/postgrey/
  
  but that doesn't fix the problem.  Whatever it is, it looks to be deeper
  than simply an incompatible database update.
 
 My workaround has been to simply disable the broken part on line 249:
 
 if(0 and $hour  1 and $hour  7 and
 $now - $self-{postgrey}{last_maint_keys} = 82800)

Well, that means your database never gets cleaned.  I was going to say
that simply restarting at least meant the main database got cleaned
(because it's crashing on the AWL transaction).  However, I stripped the
cleaning code from postgrey and ran it on a copy of the database.  In
spite of the fact that there's no error on the first $txn-commit(), the
transaction hasn't committed.  The next transaction you try to create in
the $db_env is empty, which is why the crash.

What's even stranger is that the entire db and db_cawl ties look to be
non functional after $txn-commit() ... it's like setting up the
transaction actually causes the entire perl DB mechanism to fall over.

This all smells like a libdb5.1 problem.

If I remove the transactions and just do a straight delete, everything
works (at least in my test environment; I'll try it on the real program
tonight).  There's actually no real reason for the deletes to be done
transactionally.  Even if we get a crash, we don't care whether all the
keys or none are deleted ... if we get partial deletion, the next
cleanup will get the rest.

James





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#614968: has now impacted testing

2011-03-04 Thread James Bottomley 
I picked this up on a recent testing upgrade (last Saturday).  My
postgrey process is now dying every night as well (I've set up a harness
to restart it, but it's not ideal).

Following what happened in #441069 I tried

db5.1_recover -h /var/lib/postgrey/

but that doesn't fix the problem.  Whatever it is, it looks to be deeper
than simply an incompatible database update.

James





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#614968: has now impacted testing

2011-03-04 Thread Joey Hess 
James Bottomley wrote:
 I picked this up on a recent testing upgrade (last Saturday).  My
 postgrey process is now dying every night as well (I've set up a harness
 to restart it, but it's not ideal).
 
 Following what happened in #441069 I tried
 
 db5.1_recover -h /var/lib/postgrey/
 
 but that doesn't fix the problem.  Whatever it is, it looks to be deeper
 than simply an incompatible database update.

My workaround has been to simply disable the broken part on line 249:

if(0 and $hour  1 and $hour  7 and
$now - $self-{postgrey}{last_maint_keys} = 82800)

-- 
see shy jo


signature.asc
Description: Digital signature