Bug 127707
Summary: | rfe: patch: slony replication engine | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kaj J. Niemi <kajtzu> | ||||
Component: | postgresql | Assignee: | Tom Lane <tgl> | ||||
Status: | CLOSED DEFERRED | QA Contact: | |||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | hhorak, lowen | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2004-07-12 19:59:44 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Kaj J. Niemi
2004-07-12 19:35:52 UTC
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 compile against). 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 1-2 years. |