Re: Postgres-R: primary key patches - Mailing list pgsql-hackers

From Markus Wanner
Subject Re: Postgres-R: primary key patches
Date
Msg-id 488611FA.3030907@bluegap.ch
Whole thread Raw
In response to Re: Postgres-R: primary key patches  (Dimitri Fontaine <dfontaine@hi-media.com>)
List 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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Plans for 8.4
Next
From: Zdenek Kotala
Date:
Subject: Re: [WIP] collation support revisited (phase 1)