On Thu, 2010-05-06 at 12:03 -0700, Josh Berkus wrote:
> So changing to a lock-based mechanism or designing a plugin interface
> are really not at all realistic at this date.
I agree that changing to a lock-based mechanism is too much at this
stage of development.
However, putting in a plugin is trivial. We could do it if we choose,
without instability or risk. It is as easy a change as option (1). It's
not complex to design because it would use the exact same API as the
internal conflict resolution module already does; we can just move the
current conflict code straight into a contrib module. This can be done
bug-free in about 3 hours work. There is no performance issue associated
with that either. Plugins would allow all of the various mechanisms
requested on list over 18 months, nor would they prevent including some
of those options within the core at a later date.
Without meaning to cause further contention, it is very clear that
putting in contrib modules isn't bad after all, so there is no material
argument against the plugin approach.
I recognise that plugins for some reason ignite unstated fears, by
observation that there is always an argument every time I mention them.
I invite an explanation of that off-list.
> Realistically, we have two options at this point:
>
> 1) reduce max_standby_delay to a boolean.
>
> 2) have a delay option (based either on WAL glob start time or on system
> time) like the current max_standby_delay, preferably with some bugs fixed.
With a plugin option, I would not object to option 1.
If option 1 was taken, without plugins, it's clear that would be against
consensus.
Having said that, I'll confirm now there will not be an extreme reaction
from me if option (1) was forced, nor do I counsel that from others.
> I said it before and I'll say it again: "release early, release often".
None of this needs to delay release.
-- Simon Riggs www.2ndQuadrant.com
