Red Hat Bugzilla – Bug 127707
rfe: patch: slony replication engine
Last modified: 2013-07-02 23:01:47 EDT
Description of problem:
It would be nice if the slony-1 replication engine was available from
the distribution. As currently it can't be built without a compiled
postgresql source tree it only makes sense to include it. The attached
patch against postgresql 7.4.3-2 does so.
Version-Release number of selected component (if applicable):
Created attachment 101823 [details]
patch against postgresql.spec (7.4.3-2)
Slony isn't even out of beta yet. When it gets past the "version 1.0" stage, we'll consider
including it in Fedora. It won't be part of the core postgresql package though --- that
would create severe release-management headaches, since slony is not on the same
release schedule as core Postgres.
However, Tom, Slony requires a source tree on which to compile, so
while separate packaging would be the nicest, is it even possible
without a slony source RPM duplicating the postgresql source tree?
Slony 1.0 non-beta has been released, incidentally.
As it is a goal of mine to have the slony engine be the mechanism for
upgrades, I personally want to include it, even though it will be a
release headache. The nice part is that it can be compiled against
any source tree, not just the latest version (although there is a
sunrise version for it, I think 7.3 is the earliest tree it will
If Slony needs a source tree, then that's a Slony bug we'll have to fix ;-). I can't see a
reason why it shouldn't be able to get by with the headers provided by the postgresql-
devel RPM. Considering that it's supposed to be backend-version-independent, it can't
really be touching any deep dark source code.
I think it would be an absolutely fatal packaging error to put Slony into the same specfile
as Postgres. We would very soon find ourselves in binds like having an older version of
Slony in RPMs that are newer according to the RPM version number (because it's a newer
PG release). That would mean that an "upgrade" could cause a user's system to go
backwards. BTW, we need to break JDBC and pygresql out too, for the same reason.
If you want to use Slony to support upgrades, we could conceivably make the postgresql-
server package depend on the slony package. (I do not think this would create any
circularity, because the slony-to-postgresql-devel dependency would be at build time not
install time.) However, you have previously given lots of cogent reasons why trying to
upgrade during RPM install is a bad idea, and I don't see that Slony eliminates any of those
reasons. So I think we're still going to have to do the thing with concurrent installations of
two Postgres versions.
Just having the header files around isn't enough. :( The postgresql
sources needed to be compiled successfully with some sane options
before attempting to compile slony-1.
A completely separate package is okay with me. I seem to need slony-1
for a replication project and would like not to do OSS work that goes
away from the upstream since it gets to be a maintenance issue after