Bug 127707 - rfe: patch: slony replication engine
rfe: patch: slony replication engine
Product: Fedora
Classification: Fedora
Component: postgresql (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Lane
Depends On:
  Show dependency treegraph
Reported: 2004-07-12 15:35 EDT by Kaj J. Niemi
Modified: 2013-07-02 23:01 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-12 15:59:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch against postgresql.spec (7.4.3-2) (2.87 KB, patch)
2004-07-12 15:36 EDT, Kaj J. Niemi
no flags Details | Diff

  None (edit)
Description Kaj J. Niemi 2004-07-12 15:35:52 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):

Additional info:
Comment 1 Kaj J. Niemi 2004-07-12 15:36:44 EDT
Created attachment 101823 [details]
patch against postgresql.spec (7.4.3-2)
Comment 2 Tom Lane 2004-07-12 15:59:44 EDT
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.
Comment 3 Lamar Owen 2004-07-13 11:19:26 EDT
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
compile against).
Comment 4 Tom Lane 2004-07-13 12:04:33 EDT
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.
Comment 5 Kaj J. Niemi 2004-07-13 12:49:25 EDT
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
1-2 years.

Note You need to log in before you can comment on or make changes to this bug.