Skip site navigation (1) Skip section navigation (2)

Re: Re: Hot Standby query cancellation and Streaming Replication integration

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Hot Standby query cancellation and Streaming Replication integration
Date: 2010-02-26 20:22:56
Message-ID: 1267215776.11463.13.camel@jd-desktop.unknown.charter.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, 2010-02-26 at 12:02 -0800, Josh Berkus wrote:
> > I don't see a "substantial additional burden" there.  What I would
> > imagine is needed is that the slave transmits a single number back
> > --- its current oldest xmin --- and the walsender process publishes
> > that number as its transaction xmin in its PGPROC entry on the master.
> 
> If the main purpose of the slave is long-running queries, though, this
> could cause a lot of bloat on the master.  That's a special case, but a
> reason why we would want to preserve the stop replication functionality.
> 

Do we really think that users, using the slave to run long-running
queries is a special case? One of the number one things I can see this
being used for is reporting....

Sincerely,

Joshua D. Drake


-- 
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.


In response to

pgsql-hackers by date

Next:From: Aidan Van DykDate: 2010-02-26 20:25:33
Subject: Re: Re: Hot Standby query cancellation and StreamingReplication integration
Previous:From: Tom LaneDate: 2010-02-26 20:21:05
Subject: Re: Re: Hot Standby query cancellation and Streaming Replication integration

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group