On 7/26/2006 5:03 AM, Csaba Nagy wrote:

>> OK I thought there might have been a 'dry run' in a BEGIN/ROLLBACK block which watched which tables were being affected. Is this kind of thing planned for a future release?
> 
> Well, if your script adds a column with default value to a huge table I
> guess you wouldn't want a dry run first ;-) I certainly won't like slony
> doing that by default.
> 
>> That I don't understand, because I specified the script to run on set 2, but I am only seeing deadlocks on tables which are only in set 1! :(
> 
> OK, then is it possible that your script affects those tables outside
> the set ? It is possible for example if you modify foreign key relations
> which point outside the set. That's why the slony docs state pretty
> clearly you should stuff all tables related by FKs into the same set...

No. A while back we decided to extend the locking (and fixing the system 
catalog screwups) to all tables in all sets. Otherwise it is impossible 
to have one script alter tables in more than one set, and it is 
extremely dangerous if there are referential integrity constraints 
across sets.

The thing I don't understand is how can this sort of schema changes be 
required in the middle of the day without the need to shutdown and 
upgrade the application at the same time?


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #