On Thu, Oct 18, 2012 at 9:49 AM, Peter Geoghegan <pe...@2ndquadrant.com> wrote: > On 16 October 2012 15:26, Jan Wieck <janwi...@yahoo.com> wrote: >> This means that the transition time from the existing, trigger based >> approach to the new WAL based mechanism will see both technologies in >> parallel, which is no small thing to support. > > So, you're talking about a shim between the two in order to usefully > support inter-version replication, or are you just thinking about > making a clean break in compatibility for Postgres versions prior to > 9.3 in a new release branch?
It's early to assume either. In Slony 2.0, we accepted that we were breaking compatibility with versions of Postgres before 8.3; we accepted that because there were considerable 'manageability' benefits (e.g. - system catalogues no longer hacked up, so pg_dump works against all nodes, and some dramatically reduced locking). But that had the attendant cost that we have had to continue fixing bugs on 1.2, to a degree, even until now, because people on Postgres versions earlier than 8.3 have no way to use version 2.0. Those merits and demerits apply pretty clearly to this. It would be somewhat attractive for a "version 2.3" (or, more likely, to indicate the break from earlier versions, "3.0" to make the clean break to the new-in-PG-9.3 facilities. It is attractive in that we could: a) Safely remove the trigger-based log capture apparatus (or, at least, I'm assuming so), and b) Consciously upgrade to take advantage of all the latest cool stuff found in Postgres 9.3. (I haven't got any particular features in mind; perhaps we add RANGE comparators for xid to 9.3, and make extensive use of xid_range types? That would be something that couldn't reasonably get hacked to work in anything before 9.2...) c) Drop out any special cases having to do with support of versions 8.3, 8.4, 9.0, 9.1, and 9.2. But, of course, we'd be leaving everyone running 8.3 thru 9.2 behind, if we did so, and would corresponding shackle ourselves to need to support the 2.x branches for still longer. And this would mean that this Slony "3.0" would expressly NOT support one of our intended use cases, namely to support upgrading from elder versions of Postgres. A "shim" adds complexity, but retains the "upgrade across versions" use case, and reduces the need to keep supporting elder versions of Slony. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
