From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hot Standby query cancellation and Streaming Replication integration |
Date: | 2010-02-27 00:54:57 |
Message-ID: | 201002270054.o1R0svG06834@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Smith wrote:
> You can think of the idea of passing an xmin back from the standby as
> being like an auto-tuning vacuum_defer_cleanup_age. It's 0 when no
> standby queries are running, but grows in size to match longer ones. And
> you don't have to have to know anything to set it correctly; just toggle
> on the proposed "feedback xid from the standby" feature and you're safe.
Yes, there is no question there is value in passing the xid back to the
master. My point is that it is like your blog entry:
http://blog.2ndquadrant.com/en/2010/02/tradeoffs-in-hot-standby-deplo.html
you can't have all the options:
1. agressive vacuum on master
2. fast recovery of slave
3. no query cancel on slave
Again, pick two. Passing the xid back to the master gives you #2 and
#3, and that might be good for some people, but not others. Do we have
any idea which options most administrators would want? If we get xid
passback to the master, do we keep the other configuration options?
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-02-27 01:53:13 | Re: Hot Standby query cancellation and Streaming Replication integration |
Previous Message | Mark Mielke | 2010-02-27 00:50:11 | Re: Avoiding bad prepared-statement plans. |