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

From Jan Wieck
Subject Re: Proposal: Commit timestamp
Date
Msg-id 45CCFA63.5090502@Yahoo.com
Whole thread Raw
In response to Re: Proposal: Commit timestamp  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On 2/9/2007 3:25 PM, Andrew Dunstan wrote:
> Richard Troy wrote:
>> On Fri, 9 Feb 2007, Andrew Dunstan wrote:
>>   
>>> Richard Troy wrote:
>>>     
>>>> 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.
>>>>       
>>> I understand that you're just thinking aloud, but overloading namespaces
>>> in this way strikes me as awful. Applications and extensions, which are
>>> the things that have need of namespaces, should not have to care about
>>> replication. If we have to design them for replication we'll be on a
>>> fast track to nowhere IMNSHO.
>>>     
>>
>> Well, Andrew, replication _is_ an application. Or, you could think of
>> replication as an extension to an application. 
> 
> No, I don't think of it as either. It's a utility, more an extension of 
> the DBMS than of the application. You don't replicate for the sake of 
> replicating.
> 
>> I was under the impression
>> that_users_ decide to put tables in schema spaces based upon _user_ need,
>> and that Postgres developer's use of them for other purposes was
>> incroaching on user choices, not the other way around.
> 
> That's exactly what you would be doing with this proposal, encroaching 
> on what I regard as user space.

I'd never use a schema for that. Look at Slony-I. It uses a user 
selectable schema for the stuff it needs to store in the database, to 
keep Slony objects separate from user objects. But it organizes the user 
tables in what is called sets. A set can be any combination of tables 
and sequences from any number of namespaces. If I would do it again, I 
would use names instead of numbers to identify sets, and I would allow 
for summary sets containing groups of simple sets.

On the other issue, replication is part of the overall infrastructure 
and thereby part of the solution to a business problem. Like the 
hardware, database and application it solves a piece of the puzzle, none 
of the other is particularly good at. It will perform better or 
eventually not at all, depending on how much consideration the 
distributed nature of the business model was given when the application 
was designed. Applications that "happened by accident" rather than being 
designed usually don't allow any kind of distribution.

And yes, there are people who replicate for the sake of it. It is the 
kind of people who ask for sync multi-master no matter what their actual 
problem might be, because it sounds most prestigious.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Variable length varlena headers redux
Next
From: "Simon Riggs"
Date:
Subject: Re: HOT for PostgreSQL 8.3