Re: Proposal: Commit timestamp - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: Proposal: Commit timestamp |
Date | |
Msg-id | 200702090349.l193nqv01986@momjian.us Whole thread Raw |
In response to | Re: Proposal: Commit timestamp ("Joshua D. Drake" <jd@commandprompt.com>) |
List | pgsql-hackers |
I just want an outline of what each option is supposed to control. If that information is in a documentation patch, then fine, he can just post that and tell people to read the patch documentation. --------------------------------------------------------------------------- Joshua D. Drake wrote: > Jan Wieck wrote: > > On 2/8/2007 3:32 PM, Bruce Momjian wrote: > >> Alvaro Herrera wrote: > >>> > > Is this a new policy that after discussion, all patches must be > > >>> > resubmitted with a summary and conclusions of the discussion? I can > >>> > > certainly do that for you, but just tell me if you are going to > >>> ask the > > same from everyone. > >>> > > No, I am asking only this time because I feel there was too much > >>> > disconnect between the patch and the extensive replication discussion > >>> > that few community members would see the connection. > >>> > >>> FYI, in my opinion the trigger addition is clearly useful to Mammoth > >>> Replicator as well. In fact, it's so obviously useful that I didn't see > >>> a need to state that in the original thread where it was discussed. > >> > >> Right, I know it is useful too, but I would like a layout of what it > >> does and why so everyone is clear on it. > > Well how deep are we talking here? My understanding of what Jan wants to > do is simple. > > Be able to declare which triggers are fired depending on the state of > the cluster. > > In Jan's terms, the Origin or Subscriber. In Replicator terms the Master > or Slave. > > This is useful because I may have a trigger on the Master and the same > trigger on the Slave. You do not want the trigger to fire on the Slave > because we are doing data replication. In short, the we replicate the > result, not the action. > > However, you may want triggers that are on the Slave to fire separately. > A reporting server that generates materialized views is a good example. > Don't tie up the Master with what a Slave can do. > > Sincerely, > > Joshua D. Drake > > > > > > > I have no clue what got you into what you are doing here. But that shall > > not be my real concern. If you feel the need to do this sort of thing, > > be my guest. I will add the remaining changes to pg_rewrite, including > > the new support commands and changes to psql as well as pg_dump and > > resubmit the new patch with explanations that will hopefully help you to > > comprehend what and how this relatively small and fully backward > > compatible change in the trigger and rule firing mechanism will work and > > what existing problems it will solve. > > > > > > Regards, > > Jan > > > > > -- > > === The PostgreSQL Company: Command Prompt, Inc. === > Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 > Providing the most comprehensive PostgreSQL solutions since 1997 > http://www.commandprompt.com/ > > Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate > PostgreSQL Replication: http://www.commandprompt.com/products/ > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
pgsql-hackers by date: