[Bucardo-general] b5: delta_ rows not being deleted

[Greg Sabino Mullane]

On Sat, Dec 08, 2012 at 12:08:32AM -0500, Bill McGonigle wrote:
> Hi, all,
> 
> b5 replication is working well, but looking at my system graphs I
> see the database is growing fairly linearly.  Long story short,
> bucardo_purge_delta doesn't seem to do anything because there's a
> matching txntime table still in the delta_ table.  So, both delta_
> and track_ continue to grow.
> 
> b5 is running vac as expected, just nothing's being cleaned up.  I
> didn't see in the .pm where the delta_ delete is supposed to run.
> Maybe somebody can clue me in on where that happens.

I did some quick testing, and things appear to be working as expected. 
Are you sure you have the right number of entries in the 
bucardo_delta_targets table? That's usually the cause of 
bucardo_purge_delta not working as expected. Each table should 
have one entry in that table, per sync that is using it. The number 
must match the number of entries in the track table before any 
deletion will occur.

Not sure off the top of my head why we store sync and not dbgroup 
in the bucardo_delta_targets table, but it is late and my head is 
fuzzy. Can someone on this list (David?) look over that concept 
and see if it sane? It seems to me we use dbgroup in the track table 
so that multiple syncs can post to the same dbgroup as needed (and 
thus not replicate things more than once), but shouldn't we also 
in that case assign the dbgroup name, not the sync name, inside 
bucardo_delta_targets? Otherwise we may end up with the OPs case 
in which the VAC daemon fires but does nothing, as two syncs with 
the same dbgroup will only ever create a single txntime track/stage 
match, but will always have two _targets entries.

-- 
Greg Sabino Mullane greg at endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20121224/60b356ca/attachment.sig>