Re: [GENERAL] Postgresql CBT
On 05/24/2011 08:05 AM, sade...@yahoo.com wrote: Id like to familiarize with postgresql and looking for a decent CBT but not able to find it. Could someone help pls? And CBT is? (First hit on Google reads Cognitive behavioral therapy, but I somehow doubt that's what you are interested in...) Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] PostgreSQL Conference 2009 Japan
Hi, I've added a wiki page with some information you might find helpful, if you are attending the PostgreSQL Conference 2009 in Japan. However, I've never been to Tokyo before, so please feel free to correct and add better links, hints and recommendations: http://wiki.postgresql.org/wiki/PostgreSQL_Conference_2009_Japan I'd personally like to stay in a hotel with other fellow hackers, as those late night discussions tend to be very inspiring as well. So, what hotel do you plan to stay at? Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Maximum transaction rate
Hi, Martijn van Oosterhout wrote: And fsync better do what you're asking (how fast is just a performance issue, just as long as it's done). Where are we on this issue? I've read all of this thread and the one on the lvm-linux mailing list as well, but still don't feel confident. In the following scenario: fsync - filesystem - physical disk I'm assuming the filesystem correctly issues an blkdev_issue_flush() on the physical disk upon fsync(), to do what it's told: flush the cache(s) to disk. Further, I'm also assuming the physical disk is flushable (i.e. it correctly implements the blkdev_issue_flush() call). Here we can be pretty certain that fsync works as advertised, I think. The unanswered question to me is, what's happening, if I add LVM in between as follows: fsync - filesystmem - device mapper (lvm) - physical disk(s) Again, assume the filesystem issues a blkdev_issue_flush() to the lower layer and the physical disks are all flushable (and implement that correctly). How does the device mapper behave? I'd expect it to forward the blkdev_issue_flush() call to all affected devices and only return after the last one has confirmed and completed flushing its caches. Is that the case? I've also read about the newish write barriers and about filesystems implementing fsync with such write barriers. That seems fishy to me and would of course break in combination with LVM (which doesn't completely support write barriers, AFAIU). However, that's clearly the filesystem side of the story and has not much to do with whether fsync lies on top of LVM or not. Help in clarifying this issue greatly appreciated. Kind Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] High cpu usage after many inserts
Hi, Scott Marlowe wrote: Oh, what is an LMS? A Learning Management System, not to be confused with a CMS, which might also stand for a Course Management System ;-) Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] updated unofficial debian packages
Hi, Once again, I'm providing bleeding etch Debian packages: 8.3.6, 8.2.12 and 8.1.16 for Debian etch as well as for Debian lenny (or newer). However, please note that these did not run through any of the standard Debian quality assurance procedures. Use them at your own risk. For the experimental packages (for lenny or newer) use: deb http://packages.bluegap.ch/debian/postgres experimental main In addition to the newest 8.3.6 release, you also get 8.2 and 8.1 packages for lenny from there. From those packages, I've backported to etch. Note however, that these packages are not considered backports in the Debian Backports sense. The main difference between the two variants offered is that those for etch are built against TCL 8.4 (instead of the newer 8.5 for lenny). You get the etch variants with: deb http://packages.bluegap.ch/debian/postgres etch main From there, you get 8.3 (somewhat like from the official backports), 8.2 (which is no longer available from the backports) and a bleeding edge 8.1 package for etch. I've changed the directory structure, please stop using www.bluegap.ch/debian. I'm striving to keep supporting 8.1 and 8.2 for experimental, to ease upgarding without forcing users to upgrade their Postgres version. I really like the way Debian can handle multiple Postgres versions in parallel. Let's make use of that nice feature! Adding 8.3 to the mix is rather a convenience, as Martin Pitt already maintains 8.3 for experimental. Very much the same holds true for 8.1 for etch. All packages offered here have a debian revision of 0~bluegap1 or 0~bluegap1+etch1. Once an official Debian or an official backport package of the same Postgres version comes out, that overrides these due to a higher version number. Enjoy! Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Data Replication
Hi, Joshua D. Drake wrote: c) Postgres-R for multi-master data replication, appears to be a code fork of PostgreSQL Not stable as far as I know. Correct, it's not meant to be stable at this stage of development. I'm a bit disturbed by the tag code fork, which has a rather negative connotation. At the same time you compare with MySQL, featuring built-in replication. Let me simply point out and clarify, that I have absolutely no intent to fork from Postgres. Quite the opposite, I'm interested in working together with other Postgres hackers. See also FAQ 2.2: http://www.postgres-r.org/about/faqs Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Data Replication
Hi, Joshua D. Drake wrote: On Wed, 2008-12-10 at 17:18 -0500, Rutherdale, Will wrote: I attempted some searches in various areas and came up with a bewildering array of results but no clear answer. Let's extend the list even further: h) If you are up for Java, you might like Sequoia. i) Another famous player within the Postgres replication field is PgPool (available in two tasty flavors). k) Bucardo is another, pretty new async replication tool. If you tell us more precisely what you are looking for, the answers get more precise as well, I promise. :-) Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Data Replication
Hello Joshua, Joshua D. Drake wrote: I think the point is that right now Postgres-R (just like Replicator) keeps its own tree that incorporates the PostgreSQL code. ..as does every other patch for Postgres before possibly it lands on mainline. But that's neither good nor bad per se, IMO. When open sourcing replicator I tried very hard to convince myself and others that it was merely a branch of PostgreSQL. I lost that sale :P Well, yeah, maybe Postgres-R is going to loose that sale as well. But hey, it's not long ago since you've open sourced it. What makes you think that you've already lost that sale? I for example didn't find time to look at the Replicator sources up until now. However, IMO there's more to a fork than just having different source trees. When I hear of a fork, I think of something more like SQL-Ledger vs. LedgerSMB, where major disagreements play a role. Everything else is just ordinary evolution of software ;-) Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi, Gerfried Fuchs wrote: This is what formorer doesn't like, and honestly, as much as I would like to help getting things working again and support postgres users here, I have to agree with him. What solution do you have in mind for people who want Postgres 8.2 on debian etch (because they had it once it has been offered by backports)? So far I've only read that you don't like what's proposed, but I'm missing any kind of a proposal for a solution of the problem. Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi, Gerfried Fuchs wrote: Upgrade to pg8.3, the same that users of testing would have to do. And learn to see that backported packages are a moving target that gets updated. The problem only exists because upgrading is not an option. There are lots of people *wanting* to stick with Postgres 8.2 for good reasons. As long as you don't see and accept that as a problem, we keep talking across each other. pitti has made it clear that he can't reasonably support pg8.2 himself side-a-side for lenny. Your offer was there to help out with that approach but you don't seem to want to go that path neither. Don't blame me for that. My offer is to support Postgres 8.2 even for etch, as a kind of a backport (not in the sense of a Debian-backports.org-backport, but a backport of newer software to Debian etch). If that easily gives us Postgres 8.2 for lenny as well, even better! I probably want Postgres 8.2 also for lenny, as soon as that becomes stable. To help others in the same situation, I would like to offer these packages via some half-ways official channel. That turned out to be harder than I thought. So far I've only read that you don't like what's proposed, but I'm missing any kind of a proposal for a solution of the problem. So far I've only read that you don't like what's proposed, but I'm missing any kind of a proposal from you for a solution of the problem. Obviously we are talking about different problems. I'm talking about making Postgres 8.2 available for etch, because that's what I need. I am providing a solution to that problem in form of a custom repository on www.bluegap.ch/debian. Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi, Peter Eisentraut wrote: And the problem is that this scheme defines certain buckets of packages such as stable, testing, unstable, volatile, backports, etc. that have relationships between them. And unfortunately the maintenance model that Markus wants for postgresql-8.2 does not fit into any existing bucket yet. So the proper fix would be defining a new bucket, which can probably be a very difficult task. ..or simply use another bucket. I'm trying to help Martin Pitt with general purpose Postgres packaging. Maybe we can revive Postgres 8.2 for Debian that way. Or do you see any immediate problem with that strategy? Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi, Martin Pitt wrote: That's in fact the option I have most trouble with. Reason is that major upstream releases are roughly maintained for five years. All packages in Lenny main will be supported for Lenny's lifetime, which is in the order of 4 years (time to release plus, say, 3 years until the next Debian release comes out, plus one year of oldstable security/bug fix support). Understood. However, postgresql-8.2 is already a little less than 2 years old, which means that we will need to backport patches in Debian for over a year. I think it will just barely work with supporting 8.1 in Etch and 8.3 in Lenny, but 8.2 will mean trouble. That's the primary reason why I only want to support the latest version in a stable release. I just can't commit to doing all that backporting work myself. I didn't mean to put more work on your shoulders. Quite the opposite, in fact. So a compromise I can live with is to put it back into unstable (or even just experimental), but never let it propagate to testing. Then backports.org can do mechanized backports of updates without being tied to the long lifecycle of Lenny. Would that be an acceptable compromise for all involved parties? That works for me. Can you act as a sponsor for uploading 8.2 packages to experimental or unstable? Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi, Alvaro Herrera wrote: If there are no backported packages for any given Postgres major version, what will happen is that a lot of people will be forced to build them from source, which is a lot worse. (There is a reason why PGDG provides RPM for all major versions, for a lot of Redhat distributions -- people do want them). Uh.. in case that didn't get clear: I've already done the backports of Postgres 8.2.9 and 8.2.10 for debian etch. You can get these packages from the temporary repository here: http://www.bluegap.ch/debian/ Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi, Magnus Hagander wrote: Not having followed the whole discussion here.. But if location is the only issue, we could perhaps provide a repository on the postgresql.org servers for this, in case Debian does not want it on their official ones? Thanks for the offer, but location is not really the issue here. I'm in contact with Martin Pitt, who's the only maintainer of the Postgres packages for Debian. Helping him with maintaining these packages is a good thing per se, IMO. I'm trying to join forces and not diversify. Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
packages across all Postgres major versions since 8.1. And as long as Postgres upstream itself provides updates and bugfixes. I fail to see the arrogance in that. And at least for me, it's more practical than being forced to upgrade. It's just less work. I am not even talking about the effort of doing the backport. I would happily support maintaining the pg 8.2 backports for longer, it just doesn't make that much sense to me, especially not doing the work on a voluntary basis when I'm not convinced myself by the big usefulness for it. That's fine. You don't need to do it. I already did. Unfortunately, you don't seem to understand how the Debian infrastructure works That's obviously true to some extent. I'm trying to figure out and understand. That would also mean maintaining them in unstable, too, just to get things straight. And there just isn't enough power to do so properly, unfortunately. Refusing help isn't exactly going to encourage others. Well, it's pretty sure by now that Postgres 8.3 will be shipped with lenny. That wasn't the question. You can't be completely sure (long delays have happened in the past), and at the time you can be sure quite some people already starting to test upgrades so the reason for preparing the backport might already be pretty little. Agreed. Keeping to maintain all major Postgres versions in testing (and unstable) would solve that issue as well. But it was *NOT* done silently. I'm sorry if you haven't followed the list before, but it was announced on the list (backports-users, that is - and that's the list people using backports.org are meant to read). True. Sorry. Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi, Martin Pitt wrote: So it's not a lot of work, but it must be done regularly and in time. That's good news. And about my experience when backporting 8.2.9 and 8.2.10 for etch as well. Do I understand correctly, that https://code.launchpad.net/postgresql currently holds the debian packaging files in a bazaar repository? Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi,
I enjoy discussing and I think we are getting closer to an understanding
with every mail.
Gerfried Fuchs wrote:
It would have to flow from the main pool to backports. I am no
authority here, even though I understand that it might sound a bit like
it, but I don't see the chances for the exception in this case.
Okay. Looks like I'm rather trying to join the official packaging team
and bring Postgres 8.2 back alive on testing. We'll soon see how that
turns out.
To have newer features within a small subgroup of packages. Take e.g.
the pidgin package. It was updated several times with newer features but
also changed interfaces. A backported package is per definition a moving
target and not a static content, otherwise you won't ever be able to
update it at all.
I think the main difference in understanding here is the updatability of
Postgres. I'm clearly thinking of Postgres 8.2 as a very different
package than Postgres 8.3.
We have more than one server where we are running *both* in parallel and
want to keep it that way. (Where we is Programmfabrik GmbH again). (In
fact even one where an additional 8.1 is running).
I think it's quite similar to python2.{3,4,5}.: sure one can
theoretically upgrade (with enough time and resources). But more often
enough one simply doesn't want to.
No. Striving to not affect the high stability of the _base_ system is
why it's done. While striving to have high stability for the packages
within backports, it's core reason of existence is to *not* influence
the base system unto which it's applied to.
I fail to see how that can be a reason for backports to exist. If your
main motivation is not to influence the base system, you certainly don't
need any backports.
Backporting always is a compromise between stability (of the old
software) and new features, IMO.
The front page continues to explain:
Backports are recompiled packages from testing (mostly) and unstable
(in a few cases only, e.g. security updates)
So there must already be other exceptions for good reasons.
Yes. But pg 8.2 is neither in testing nor in unstable.
Agreed.
Sorry to say so then but your wording was badly chosen in some parts. I
don't deny that propably mine too, and given that we both seem to be
German natives discussing this in English even sounds like fishing for
even more problems here.
Yeah...
I never really denied that. It's just that it wouldn't follow the
current workflow that did hinder me to maintain it in the way it was
before...
Understood.
I've been coming from another direction, thinking that adding Postgres
8.2 to only backports would be easier than adding it to Debian proper.
Maybe that's plain wrong. And Martin Pitt seems to be glad to get some
help...
Because the way you worded your mails made it sound like you wanted to
have some rules enforced that are out of the scope of the lists you post
to.
Sorry if it sounded that way. I just wanted to know in what direction I
should go with Postgres 8.2 packages.
And yes, I must admit that I've been a bit disappointed by suddenly
(didn't read the backport-users...) missing Postgres 8.2 upgrades.
I won't explain further here why I called that attitude arrogant, we
can do that in private and propably in German to reduce the language
barrier. And I'm glad to hear that you want to join the packaging team,
thanks.
Cool.
If you like and don't hold this discussion against me feel free to
pester me with anything you like to. :)
Thanks for the offer. I'm trying keep the discussion on the topic and to
avoid personal offense.
Keeping to maintain all major Postgres versions in testing (and
unstable) would solve that issue as well.
If we are able to work it out I'm all for doing so.
I'll try.
No worries - and like hinted above, I'm also sorry for having sounded
pretty strict, but I just wanted to point the things out properly
instead of doing it like some others with a no, won't work reply. ;)
Hehe.. it certainly helped me better than than, yeah. Thanks for
productive criticism.
Regards
Markus Wanner
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi Martin,
Martin Pitt wrote:
Indeed it was quite clear to me right from the beginning that Lenny
would ship with 8.3 only. I think from the POV of not supporting
several PostgreSQL versions in stable Debian releases there is no
disagreement. Etch is an exception because we needed 7.4 to get an
upgrade path from Sarge, but further Debian versions will only ever
support the latest PostgreSQL release.
Okay.
I'm personally ok with that argument, but I'm not the backports.org
maintainer. If they have a general policy that they don't *ever*
upload something manual to backports.org, I suppose changing that
policy just for PostgreSQL is hard to do.
Of course there is always the possibility of offering a private
archive. For example, I maintained 8.1 backports for Sarge on
people.debian.org for quite a while, until backports.org got them.
Yeah, looks like that's what I will have to do, then.
Not my favourite option, but if the postgresql maintenance team would
actually double in size (IOW, would not just be me), and
debian-{release,security}@ don't veto, it's ok with me.
Good to hear. I'll see what I can do. Or you can let me know how to help
out. (The learning curve for becoming a Debian Maintainer or Uploader is
rather steep, IMO).
I still maintain 8.2 for Ubuntu 7.04 and 7.10, which I will have to do
for the next 7 months still. But after that I can get that off my
plate, and just maintain 8.1 and 8.3.
Aha, I'm going to compare those against my 8.2 backports, as there's
already a complaint about missing files in the -dev package.
That would basically lift backports.org to be an officially supported
Debian archive, which it isn't, and shouldn't be.
Well, there are exceptions to their rule. I think Postgres would make
another good exception. (CCing to backports because of this statement...)
So, if the backports.org maintainers are ok with manual 8.2 uploads,
and you are willing to maintain them, that works for me. In that case
I'm happy to check your packages, and to discuss QA'ing procedures for
uploads.
Cool.
If that violates the backports.org policy, I'd rather ask them to
remove the 8.2 backport altogether, since it just doesn't make sense
any more and just bitrots.
They already have.
Regards
Markus Wanner
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
for adding pg 8.3 to backports.org, I thought it would be a service to the users, but if it seems to cause more headaches for some people than benefits I propably will have to take the consequences and refrain from doing the packages for lenny-backports and do them just for myself privately again. Again, please don't be sorry. I appreciated having 8.2 (and now 8.3) available from the backports. So do lots of other users, AFAICT. However, silently removing a major version is not an option, IMO. Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Postgres major version support policy on Debian
Hi, first of all: thanks for packaging Postgres for Debian. I'm willing to help with that. Unfortunately we are stuck with several Postgres 8.2 installations from etch backports, which are no longer maintained by the backports, because only 8.2 got dropped from testing. I'm providing upgraded packages for Postgres 8.2 on my own website [1]. There are certainly other people who have run into the same issue, see for example [2] who dislikes using Postgres backports for exactly that reason. Upgrading via pg_upgradecluster is definitely not an option due to custom build extensions and because of the downtime involved. On the backports-users mailing list I've requested that Postgres 8.2 gets re-added to etch-backports, with upgraded packages. So that existing installations can get bug- and security fixes for that Postgres versions. One argument for rejection [3] has been, that Postgres 8.2 is not in testing anymore and can thus not be backported. I'm arguing that Postgres 8.2 is a backport per se. Not from testing, but a backport of newer software to etch. Anyway, I'd like to reach an agreement on a decent policy about Postgres major version support especially WRT the backports. I see these options: * Postgres major versions that once got included should continue to be supported and updated within the standard Debian infrastructure as long as supported by the Postgres project itself. * Postgres major versions dumped from testing, but once added to any backport should be maintained on backports even if it gets dumped from testing. * Never include Postgres major versions from testing in the backports, as those might get dumped from testing thus support cannot be guaranteed anymore. (Except perhaps when we can be very sure that this won't happen). Looking at it that way, I'm favoring the first option. However, I'd be fine with the second as well. The third would be a pity, but still better than status quo (because backports currently makes false promises about maintenance of backported Postgtres major versions, IMO). As already mentioned, I'm offering help in maintaining these packages. I'm somewhat experienced in Debian packaging, but not familiar with uploading or maintaining official packages (keen to learn, though). Regards Markus Wanner [1]: announcement of my Postgres 8.2 backports: http://lists.backports.org/lurker-bpo/message/20080923.161529.60f37f97.en.html [2]: newish complaint on the postgres performance mailing list: http://archives.postgresql.org/message-id/[EMAIL PROTECTED] [3]: backport policy argument, see also rest of the thread http://archives.postgresql.org/message-id/[EMAIL PROTECTED] -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Debian packages for Postgres 8.2
Hi, Peter Eisentraut wrote: As a matter of policy, backports are made from Debian testing. Continued maintenance of PG 8.2 packages is not really backporting, since there is nothing to backport from. While that's certainly true, I think there's enough of a reason for an exception. Otherwise the efforts to backport any newer Postgres major version could be saved entirely, because you never known if it suddenly ceases from testing and backports. So, please, either decide to backport a Postgres major version and continue to update it even if it gets dropped from testing *or* don't backport it at all. Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Debian packages for Postgres 8.2
Hi, Peter Eisentraut wrote: I understand how this use case ends up falling through the cracks. But the backports infrastructure is not set up for maintaining original packages (which PG 8.2 would be become, without a references package in testing). Uh.. so you are proposing to keep (revive) postgresql-8.2 in testing and backporting from there? That sounds like more trouble and work. Or do you think that's feasible? Doesn't that violate the policy of 'testing'? Otherwise, as stated, I'd recommend to never backport a Postgres major version which may be removed from testing in the future. Just to keep users from believing it's safe to use and maintained. Either way is better than status quo of Postgres in backports, IMO. (Which relies on the flaky assumption that pg_upgradecluster can be used to upgrade between major versions). So you will probably have to put in a bit more effort to come up with a sustainable maintenance model, plus the resources to enact it. Well, I'm providing the necessary packages for i386 and amd64. And I'm offering to maintain them. But I am not in the position to decide where to make these available - besides offering them from my own server as I already do. I'd be happy to upload to testing or etch-backports or both... or even help maintaining the official Postgres packages for Debian. Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Debian packages for Postgres 8.2
Hi, I'm running several productive servers on Debian etch (stable) with Postgres 8.2 which has been in lenny (testing) and made available for etch through the backports project [1]. Unfortunately, they discontinued maintaining 8.2 and switched to 8.3 in testing and thus also for the backports. As I don't currently want to switch to 8.3 due to the involved downtime and upgrading troubles involved. So I've compiled up to date Debian packages for Postgres 8.2.10. You can get them (maybe just temporarily) from here: http://www.bluegap.ch/debian, I'm providing packages as etch-backports for amd64 and i386. Upgrading from earlier 8.2 backports should work just fine. I'm trying to convince the backports people to re-add Postgres 8.2. As soon as that happens my own repository will probably disappear again. Please drop me a note if you are interested in 8.2 for etch. (Postgres 8.3 should become available via the backports within a few days, I guess). Regards Markus Wanner [1]: backports of newer software for stable Debian versions: http://www.backports.org -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
