Re: [HACKERS] Proposal: Commit timestamp

On Friday 09 February 2007, Jan Wieck wrote: > I am not sure, I would have to look at what exactly that hook provides. > The key to a Lamport timestamp is that it is advancing it commit order > (plus some other things ... of course). If the hook can guarantee that > the calls are made always in com

Re: [HACKERS] Priorities for users or queries?

Benjamin Arai wrote: > Is there a way to give priorities to queries or users? Something similar to > NICE in Linux. My goal is to give the updating (backend) application a very > low priority and give the web application a high priority to avoid > disturbing the user experience. > > Thanks in a

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

Jan Wieck wrote: > On 1/25/2007 7:33 PM, Tom Lane wrote: > > > > 1 fires always > > 0 fires never > > N fires in "Normal" mode > > R fires in "Replica" mode > > other letters available for other future mode values? > > > > If you cons

Re: [HACKERS] Proposal: Commit timestamp

On Saturday 03 February 2007, Bruce Momjian wrote: > Jan Wieck wrote: > > I don't have any such paper and the proof of concept will be the > > implementation of the system. I do however see enough resistance against > > this proposal to withdraw the commit timestamp at this time. The new > > replic

Re: [HACKERS] Replication hooks discussion

On Friday 29 September 2006 20:02, Andrew Sullivan wrote: > At the beginning of the month, in > , > I said that I'd be willing to try to do any sort of co-ordination, > document writing, &c. for a project that might define common ba

Re: [HACKERS] standard interfaces for replication providers

On Wednesday 09 August 2006 20:57, Hannu Krosing wrote: > > > > Why reinvent the wheel for everything if there was an interface that > > offered some of the needed functionality? Maybe PostgreSQL-R is simply > > too deep in the database for any of this to be useful, but I'm 99% > > certain that Slo

Re: [HACKERS] standard interfaces for replication providers

On Friday 04 August 2006 16:46, Tom Lane wrote: > We haven't been able to build production-grade multi-master replication > without the barrier of a "standard" database-agnostic API, so I kinda > doubt that it will work all that much better with one. See Slony-II. I would argue that people haven'

Re: [HACKERS] Two-phase commit issues

On Saturday 21 May 2005 03:37, Josh Berkus wrote: > 2PC is a key to supporting 3rd-party replication tools, like C-JDBC. I don't think C-JDBC requires 2PC for replication. Mixed up acronyms maybe? :) -- Jose Orlando Pereira ---(end of broadcast)--

Re: [HACKERS] Two-phase commit issues

On Friday 20 May 2005 18:14, Tom Lane wrote: > Bruce Momjian writes: > > As I remember, you said two-phase wasn't 100% reliable and we just > > needed a way to report failures. > > [ Shrug... ] I remain of the opinion that 2PC is a solution in search > of a problem, because it does not solve the