On Thursday 21 February 2008 12:56, Scott Marlowe wrote:
> On Thu, Feb 21, 2008 at 9:20 AM, Terry Lee Tucker <terry@xxxxxxxxxxxxx>
wrote:
> > Greetings:
> >
> > We have been working diligently toward integrating Slony into our
> > production databases. We've been having trouble with various tables,
> > although being replicated perfectly in the initial replication stage,
> > afterwards, getting out of sync.
> >
> > I have finally figured out what the problem is. We have a Perl process
> > that continually updates certain columns across all databases. That Perl
> > process calls a function we have written called disable_triggers which
> > updates pg_class, setting reltriggers to 0 for the given table, and then
> > later, after the work is complete, resetting reltriggers to the original
> > value. Unfortunately, during this process, the Slony trigger is disabled
> > as well which is causing our problem.
>
> Disabling all triggers is not something you do on a live, running
> database with users accessing and possibly changing it, it's something
> you do to a database during maintenance when no one else is connected.
> You'll have to go with the solution you talked about, i.e. disabling
> individual triggers by name, etc...
>
I have failed to mention that we are disabling all the triggers on a given
table only done during a transaction; thus, it affects no one else.
Thanks for the input...
--
Terry Lee Tucker
Turbo's IT Manager
Turbo, division of Ozburn-Hessey Logistics
2251 Jesse Jewell Pkwy NE
Gainesville, GA 30501
Tel: (336) 372-6812 Fax: (336) 372-6812 Cell: (336) 404-6987
terry@xxxxxxxxxxxxx
www.turbocorp.com
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
