I wonβt be able to test it until tomorrow, cause of sluggish network, but I tested the sample VM from yesterday (which is fine so far) and Iβm very confident for this one.
I just spent pulling my hair off for almost half a day because somewhere while updating my modules got corrupted and literally what I was writing broke
after 34ΛC the current 19Λ with rain is also GLORIUS
rsh7
iliekcomputers: bitmap: ping.
bitmap
pong
rsh7
hey, I am getting an error of this form - DETAIL: Key (id)=(22002623) is still referenced from table "track", while any delete operation is taking place (from replication packets)
aren't the referenced tables have already a delete query before in the replication packets?
bitmap
yes...but slave servers don't have foreign keys because we don't guarantee referential integrity when applying the operations in order
rsh7
oh okay, so I think I have to handle this case separately
bitmap
but assuming "Key (id)=(22002623)" is a recording that might be a bug in your script, because I can'y think of any cases where we'd be deleting a recording still referenced on a release
ashwanig has quit
Rotab
ZaphodBeeblebrox: the rain just made everything humid and horrible here :(