[Bucardo-general] Specific code or trigger to avoid race condition during row deletion in multimaster mode

[Greg Sabino Mullane]

> - All tables are updated by A, and no table are updated by B
> *except* the field "state" of the table "Events" that may be written
> by B too.
...
> I see the following solution to avoid the line "re"creation:
> 1) Change the application design to avoid machine B updating the
> Event table. But this is hard to change.
> 2) Instruct bucardo not to consider the "state"field when filling
> the delta table

It's not perfectly clear what your requirements are. When A goes down, 
do you want B to start recording all rows, including "state" changes? 

It sort of depends on how your failover plan works. If you have to do 
something manually to move things over to B (like pointing the app), 
then you could also do some Bucardo changes as well. The simplest 
way to avoid B updates going to A is to make B a target only 
in the sync (A:source,B:target). You could always setup an inactive 
sync so that B captures rows in case it starts getting written to 
such that (B:source,A:target). Once A is back up, you can flip the 
sync on to start recording changes. But at that point you might as 
well have simply had A:source,B:source in the first place! :) So let's 
look into the non-state-on-B issue:

> What is the best way to achieve 2) ?
> -I manually change the bucardo_delta trigger of the Events table by
> creating a specific UPDATE trigger with a WHEN condition that does
> not take into account the "state" field - this seems to work but I
> find this a bit "hackish" because I do it "manually".
> -There is a bucardo_custom_trigger table, can it be used for this ?

Yes - this is exactly what that table is for. Take a look at an existing 
trigger, then modify it how you need to and stick in into that table. 
You may need to run validate_sync as well as delete the original trigger.
Keep in mind that if the app ever points to B for the main database, you 
will want to remove this custom trigger!

If, as the subject line says, this is a "race condition" such that things 
are updated at the same time, then you could also simply instruct A to 
always "win" by setting the sync.conflict_strategy to "A".

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