On Tuesday 23 August 2005 14:51, Christopher Browne wrote:
> Darcy Buskermolen wrote:
> >On Thursday 28 July 2005 11:49, Christopher Browne wrote:
> >>I discovered yesterday that a couple of changes were needed to this
> >>patch to accomodate log shipping...
> >>
> >>1.  Change to remote_worker.c
> >>
> >>(I don't have a reasonable "diff of a diff"; this should be clear
> >>enough, particularly as it's only a few lines of change)
> >>
> >>@@ -2778,7 +2810,10 @@
> >>         if (archive_dir) {
> >>             slon_log(SLON_DEBUG4, "start log ship copy of %s\n",
> >>tab_fqname);
> >>             slon_mkquery(&query1,
> >>-                     "delete from %s;copy %s from stdin;", tab_fqname,
> >>tab_fqname);
> >>+                     "select %s.disableSubscriptionIndexes('%s'); "
> >>+                     "delete from %s; "
> >>+                     "copy %s from stdin;",
> >>+                     rtcfg_namespace, tab_fqname, tab_fqname,
> >> tab_fqname); rc = submit_query_to_archive(&query1);
> >>             if (rc < 0) {
> >>                 slon_log(SLON_ERROR, "remoteWorkerThread_d: "
> >>
> >>2.  Need enable/disableSubscriptionIndexes() in the initial dump...
> >
> >There is a problem with the slony1-dump patch as youhave provided, it has
> > no logic to load the correct functions depending on PostgreSQL version. 
> > I think we may have to rethink how slony1_diump.sh works both to be able
> > to deal with the above version logic, as well as prevent code
> > duplication.
> >
> >One thing we could do in the interim is to only disable indexes during
> >conventional slony operation, and ignore that during logshipping mode.
>
> Essentially, that turns disable/enableSubscriptionIndices() into NOP (no
> operation) routines, which, while "performance pessimal," isn't the
> worst thing we could possibly do.
>
> If we can put in a decent default in slony1-dump, and perhaps warn
> people that if they are running a too-{old|new} version of PostgreSQL,
> they may have to replace those functions, that's also not the worst
> possible thing to do.
>
> I'd be keener on having a PG-version-specific set of enable/disable
> functions; that's an even better improvement to the patch :-).

Yes that would be the better solution I agree, I just don't have adequate time 
to put into doing that ATM. What ever solution is finalized on I'd like to 
see it avoid code duplication to make developer maintainace less.  

> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general

-- 
Darcy Buskermolen
Wavefire Technologies Corp.

http://www.wavefire.com
ph: 250.717.0200
fx: 250.763.1759