On 10/18/2004 6:20 PM, Darcy Buskermolen wrote:

> I've come across a few situations where I've needed to drop some check 
> constraints on the subscribers to allow the initial data subscription to 
> happen.  In thinking about this I have come up with the following proposal 
> which I'd like some feedback on prior to implementing.
> 
> I propose, that rather than hacking around the system catalogs and manually 
> setting things like tg_enable=false.  That we probe each table during the set 
> table add command checking for CHECK/RULE/TRIGGERS, get the textual creation 
> syntax of these objects  (the same as pg_dump does), store these within a 
> coresponding table in the cluster schema, then issue an ALTER TABLE ... DROP 
> TRIGGER/CONSTRAINT/RULE.  These objects are then restored at the appropriate 
> time when the cluster is uninstalled, or failed-over.

This would have an IMHO undesirable side effect. There is no way to skip 
the possibly long and tedious consistency check of the existing data 
when doing "ALTER TABLE ADD CONSTRAINT" ... which is already annoying 
enough when restoring a dump.

It would destroy the almost instant switchover, since it would require 
readonly access to all nodes from the moment the old origin closes for 
update activity until the new origin has checked ALL constraints in the 
set and enables updates. Failover would take the same amount of time.

No, we definitely need to utilize tg_enabled for triggers.


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 #