On 3/19/2007 4:28 AM, Andrew Sullivan wrote:
On Sat, Mar 17, 2007 at 01:06:54PM -0400, Steve Singer wrote:
If your DDL has errors then you won't find out about it
until slon tries to execute it on the other node (slonik won't give you an
error but making changes just on your subscribers can have the potential
for all sorts of trouble if your not careful)
I think this is the reason it didn't work as expected -- I think
someone raised the objection about what sort of mess this could make.
That doesn't mean it's not useful.
This piece of functionality seems to me to be exactly the sort of area
where using savepoints on the remote note might be a good idea, but
I'm worried about the potential for really nasty locks. I think in
the medium term, we probably need a complete proposal on how to
improve EXECUTE SCRIPT's safety, or some sort of comprehensive
discussion about the various locks that are being taken and the like.
I'm slightly worried that some of the design in that area is happening
a little _ad hoc_, and I think a more complete idea of what the
trade-offs are, and which ones we can countenance, would be really
nice to have.
You can always roll the dice with a left or a right twist ... so
sometimes you want the thing to halt on error, sometimes you just want
it to skip errors. The "halt on error" implies some sort of "until"
thing ... yet to be defined. Anyhow, this means that EXECUTE SCRIPT
basically needs to perform the script itself in a subtransaction and
that another option (parameter) should tell if the outer transaction
(confirming the event) shall commit regardless or not.
This brings back the "cancel event" discussion, we had on IRC a while
back. I don't really like "cancel event" by itself because the event
might have been successfully executed on some nodes prior to being
canceled, so this opens another can of worms. But I would certainly
agree to the usefulness of some "cancel event X on node Y on error"
feature. Not that this would be easy to implement, since it somehow
implies that the node can see the future of its own event queue. Or, it
would require another Slony table "sl_events_to_ignorei_on_error".
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
_______________________________________________
Slony1-general mailing list
[email protected]
http://lists.slony.info/mailman/listinfo/slony1-general
