|
Bugzilla – Full Text Bug Listing |
| Summary: | 'drop node' in a try block | ||
|---|---|---|---|
| Product: | Slony-I | Reporter: | Steve Singer <ssinger> |
| Component: | slonik | Assignee: | Steve Singer <ssinger> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | slony1-bugs |
| Priority: | low | ||
| Version: | devel | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: | patch for a possible fix | ||
Created an attachment (id=117) [details]
patch for a possible fix
This patch allows the first useful command in a try block to be a waiting
operation. It will rollback the transaction and create a new one after the
wait.
Another alternative would be for conditionals to be handled in an "abort if
{conditions} fashion", as described in bug #173.
I think you've observed that this isn't necessarily a reason to "abort," so
perhaps that should change to "conditional execution."
Please review
Looks good to me. Please apply.
In doing some testing against the 2.1.0 beta I tried executing some slonik code like try { drop node(id=3, event node=1); } on error { echo "node already gone"; } store node(id=3, event node=1); A script like this will fail in the current 2.1.0 betas and this shouldn't surprise anyone who has read about the new features in 2.1.0 A drop node requires that the cluster be somewhat caught up (at least to the extent that any events from the drop'd node that have been confirmed elsewhere are confirmed everywhere). This means that drop node has an implicit 'wait for event' before it. However you can't have 'wait for events' inside a try block.