On 09/19/2012 03:39 PM, Bill McGonigle wrote:
>
> Will see where that's generated next...
I didn't quite figure out the code but I got far enough to understand what was
happening. I think this is probably a reportable bug in b5.
The data looked like:
# select * from related where parent_id = '3826';
parent_id | child_id | child_seq | type
-----------+----------+-----------+---------
3826 | 1796 | 0 | PRODUCT
3826 | 3483 | 1 | PRODUCT
3826 | 7599 | 2 | PRODUCT
3826 | 3667 | 3 | PRODUCT
3826 | 1859 | 4 | PRODUCT
3826 | | 5 | PRODUCT
3826 | 5 | 0 | RECIPE
3826 | 25 | 1 | RECIPE
3826 | 128 | 2 | RECIPE
(9 rows)
and the not-a-tuple it was choking on in the IN set was ('3826').
The table is defined as:
Table "public.related"
Column | Type | Modifiers
-----------+-----------------------+----------------------------------------
parent_id | character varying(15) | not null default ''::character varying
child_id | character varying(15) | not null default ''::character varying
...
So, ('3826','') does satisfy the constraints, but b5 seems to have lost the ''
along the way.
Since that row wasn't semantically meaningful for us, the recovery procedure
was:
1) delete the offending row in the source db:
DELETE FROM public.related WHERE parent_id = '3826' AND child_id='';
2) delete the same row(s) in bucardo.delta_public_related
DELETE FROM bucardo.public_related WHERE parent_id = '3826' AND child_id='';
And then restart bucardo (probably not needed).
I must say, the new b5 structure makes troubleshooting and resolution much
easier! (along with everything else working so much faster and better)
-Bill
--
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.855.SW.LIBRE
Email, IM, VOIP: [email protected]
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle
_______________________________________________
Bucardo-general mailing list
[email protected]
https://mail.endcrypt.com/mailman/listinfo/bucardo-general
