Re: Few questions on postgresql (dblink, 2pc, clustering)

On Sunday 22 August 2004 11:02, Bruce Momjian wrote:
> 2-phase isn't in 8.0 but I expect it in 8.1.

Is it possible to know when is 8.1 going to be released for production (an
estimate)?

>
> > Basically, our concern is that dblink, 2PC implementation are there, but
> > not in the PostgreSQL mainstream.
>
> You need to understand the limitations of dblink and see if it will work
> for you. I can't imagine MySQl is allowing you to do this cleanly so I
> don't see why it would hold up a MySQL -> PostgreSQL migration.

Hmm... forgive me for saying it wrongly. We're actually "thinking" of
migrating to PostgreSQL. Here's our case:

We're going to do a major upgrading on our PHP code (from PHP 3 style to PHP
5.0), and was thinking of changing the database to PostgreSQL too.
Currently, the number of transaction is not high, but we'd like to have a
more scalable solution.

MySQL does not allow cross-server database connection such as dblink. So,
we're thinking of 3 alternatives:

1) Wait for MySQL clustering to be stable and put all our databases in the
cluster
2) Migrate to PostgreSQL and use dblink to solve the referential integrity
3) Migrate to PostgreSQL clustering solution

If (2) and (3) is not viable, then we'd rather not migrate the database to
PostgreSQL for now (if it ain't broke, don't fix it)...

So, it's not actually holding us up, but just that we're not able to make
decision yet.

> > Another thing that bothers us is that we can't find any multi-master
> > clustering solution in PostgreSQL. We're actually evaluating MySQL's own
> > clustering solution, but it's production quality release is still slated
> > for MySQL 5.0.
>
> The only multi-master I know of is pgcluster. There is talking of
> moving Slony from master/slave to multi-master but work has not started
> yet.

I don't mean to be rude or anything, but having 3rd-party solution is a scary
option for a business enterprise. I know that they're stable and all, but if
it's not supported by PostgreSQL themselves (i.e. included in PostgreSQL as a
whole package), we're afraid that we have to change our code/design in case
the product has stopped progress.

For example, pgcluster's patch is for PostgreSQL 7.3.6. It's not in sync with
PostgreSQL's current version (I'm not blaming the guy... He's created a very
good solution and I'm thankful for that). It's just that for my company (and
I guess many other companies too), it's more appealing to have a database
solution that comes in a package.