Re: Postgres-R: primary key patches

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Christopher Browne <cbbrowne(at)ca(dot)afilias(dot)info>
Subject: Re: Postgres-R: primary key patches
Date: 2008-07-22 16:59:38
Message-ID: 488611FA.3030907@bluegap.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Dimitri Fontaine wrote:
> This part of Markus's mail makes me think the need may change if Postgres-R is
> ever integrated into -core:

Yes, in that case, you'd have replication already compiled in and
distributed with standard Postgres. However, ATM that's pipe dreaming
and I'm pretty sure no developer (neither me nor Postgres hackers) want
to mix code (and responsibility!) at this stage of development of
Postgres-R.

The most I'd be willing to ask for at the moment would be to get a range
of OIDs reserved for use in Postgres-R. It would not make sense at the
moment to add the schema changes to stardard Postgres, because I will
pretty have to change these again.

> So currently to use Postgres-R you'd have to start with a patched code base at
> each and every node, because it's how Markus wanted to proceed (Postgres-R
> being a separated code base). In Postgres-R adding a node to the cluster is
> what is done without dump/restore cycle.

Yup.

> Now that he's Open-Sourcing the solution, I hope to see this mode of operation
> change, thanks to integration of some key part (catalog changes) of the
> project into -core, if possible.

Sorry, but at the moment, I disagree, because I think this would
complicate matters for both projects. This might (and hopefully will)
change, sure. But we are not there, yet.

> Note that while slony doesn't require a dump/restore to get activated, it
> seems to me (as a non user of it) that it still plays with catalog,
> preventing "normal" usage of pg_dump...

Oh, does it? Well, it obviously doesn't require a Postmaster restart,
nor does it add a separate background process.

> I'm not sure which disease I prefer: not being able to dump/restore normally
> or getting to have to restore on a specific product version, not the -core
> one.

I think this process of moving between ordinary Postgres and Postgres-R
schema variants for the same(!) major version can be automated. It would
be a pretty small pg_upgrade sort of tool. I'm not that afraid of these
schema changes. Heck, in the worst case, we could even let Postgres-R
add them itself during startup.

Sorry if this sounds a little rude. I've just had the 'why isn't
Postgres-R integrated?' discussion a little too often.

Regards

Markus Wanner

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2008-07-22 17:03:26 Re: [WIP] collation support revisited (phase 1)
Previous Message Markus Wanner 2008-07-22 16:37:22 Re: Plans for 8.4