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-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
