Re: Proposal: Commit timestamp - Mailing list pgsql-hackers

From Richard Troy
Subject Re: Proposal: Commit timestamp
Date
Msg-id Pine.LNX.4.33.0702091100280.13334-100000@denzel.in
Whole thread Raw
In response to Re: Proposal: Commit timestamp  (Jan Wieck <JanWieck@Yahoo.com>)
Responses Re: Proposal: Commit timestamp  (Andrew Dunstan <andrew@dunslane.net>)
Re: Proposal: Commit timestamp  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
On Fri, 9 Feb 2007, Jan Wieck wrote:
> > [ I wrote ]
> > It'd be great if Jan considers the blending of replication;
>
> Please elaborate. I would really like to get all you can contribute.

Thanks Jan,

prefaced that I really haven't read everything you've written on this (or
what other people are doing, either), and that I've got a terrible flu
right now (fever, etc), I'll give it a go - hopefully it's actually
helpful. To wit:

In general terms, "blending of replication [techniques]" means to me that
one can have a single database instance serve as a master and as a slave
(to use only one set of terminology), and as a multi-master, too, all
simultaneously, letting the DBA / Architect choose which portions serve
which roles (purposes). All replication features would respect the
boundaries of such choices automatically, as it's all blended.

In more specific terms, and I'm just brainstorming in public here, perhaps
we can use the power of Schemas within a database to manage such
divisions; commands which pertain to replication can/would include a
schema specifier and elements within the schema can be replicated one way
or another, at the whim of the DBA / Architect. For backwards
compatability, if a schema isn't specified, it indicates that command
pertains to the entire database.

At the very least, a schema division strategy for replication leaverages
an existing DB-component binding/dividing mechanism that most everyone is
familliar with. While there are/may be database-wide, nay, installation-
wide constructs as in your Commit Timestamp proposal, I don't see that
there's any conflict - at least, from what I understand of existing
systems and proposals to date.

HTH,
Richard

-- 
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
rtroy@ScienceTools.com, http://ScienceTools.com/



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: HOT for PostgreSQL 8.3
Next
From: "Simon Riggs"
Date:
Subject: Re: HOT for PostgreSQL 8.3