You are here

PGCluster debs

Dear Lazyweb...

For a project I need to setup two freeradius server with a PostgreSQL database backend. It's intended that the freeradius server are accessing their database backends locally, i.e. on the same machine. Of course, the two database needs to be in sync.

And now there's a problem: each radius server needs to write to its database, of course, which makes such solutions as slony-1 impossible to use. Otherwise slony-1 works nicely for replication.

Next option is pgcluster which ought to be a master-master replication. Sadly, it seems that there's no Debian package. Don Armstrong tried to make one some time ago, as he told me on IRC, but due to the bad debugging options pgcluster gives, he got stuck somewhere.

So, I ask you, dear Lazyweb, if there are other options left? It's no necessary to have a full master-master replication, but in a master-slave replication writes to the DB should automatically and transparently get redirected and spooled (in case the master is unreachable). (Although is is near master-master replication ;).
Or had anyone else more luck with making PGCluster Debs? Or would like to join forces with Don Armstrong and me to make some?


PostgreSQL and Replication

Or: The Consequences of that awful Vancouver Proposal...

It's no news that I'm no big fan of the Vancouver Proposal. It's aiming into the wrong direction, IMHO, and is not very well thought through. It's basically a master plan of dropping archs.

Anyway, the more m68k is diverting from the other archs after exclusion of testing migration, the more it becomes clear what consequences this has for an arch that is going to be dropped from Debian.

Roman Zippel (a m68k hacker) summarizes some consequences quite nicely in his post to debian-68k and debian-release.

As someone who has recently looked at and fixed many problems, I must say
the release team has done m68k no service by doing this and actually
sabotaged m68k in its ability to catch up again. ...

Roman did really amazing work in tracking down and fixing the toolchain problems m68k had. Many kudos for that!
And it was some kind of obvious that the testing migration exclusion will hurt m68k more than it would help. And it will get worse and worse over time. And still the Vancouver proposal has no plan how to proceed in such a situation.

So the situation is now that m68k gets kicked out without no alternative
in place? Once the current building frenzy calms down, the situation
shouldn't look too bad and if bugs for which fixes exists in the BTS where
actually fixed, m68k could be released with just a few packages less.

True. Instead of dropping a complete arch, it would've been better to just drop some package from that arch from the release. There's a thread on -devel about this about that.

Not releasing m68k could have far worse consequences and should be
absolutely the last resort, e.g. it makes it difficult to upgrade between
stable releases, which might become a real issue, as m68k is likely to
need an ABI change for TLS support.

I doubt that anyone proposing the Vancouver plan was thinking about those kind of problems. Great job. Thank you!

As Wookey stated in the above mentioned thread on debian-devel, m68k just was the first arch and arm will follow most likely.
So, I propose to change Debians website from ''Debian is a free operating system (OS) for your computer.'' to the more appropriate ''Debian is a free operating system (OS) for your i386/amd64 computers.''


Consequences on not being an Release Arch anymore

Basically, this is my first new entry in s9y after announcing the migration from Drupal to Serendipity. There are more to come, for sure. ;)

Please feel free to leave comments, if you like...



Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer