Tom Lane wrote:
"Joshua D. Drake" <j...@commandprompt.com> writes:
On Wed, 2009-01-28 at 19:27 +0000, Simon Riggs wrote:
On Wed, 2009-01-28 at 18:55 +0000, Gregory Stark wrote:
I still *strongly* feel the default has to be the
non-destructive conservative -1.
I don't. Primarily, we must support high availability. It is much better
if we get people saying "I get my queries cancelled" and we say RTFM and
change parameter X, than if people say "my failover was 12 hours behind
when I needed it to be 10 seconds behind and I lost a $1 million because
of downtime of Postgres" and we say RTFM and change parameter X.
If the person was stupid enough to configure it for such as thing they
deserve to the lose the money.
Well, those unexpectedly cancelled queries could have represented
critical functionality too. I think this argument calls the entire
approach into question. If there is no safe setting for the parameter
then we need to find a way to not have the parameter.
We've gone through that already. Different ideas were hashed out around
September. There's four basic feasible approaches to what to do when an
incoming WAL record conflicts with a running read-only query:
1. Kill the query. (max_standby_delay=0)
2. Wait for the query to finish before continuing (max_standby_delay=-1)
3. Have a feedback loop from standby to master, feeding an OldestXmin to
the master, preventing it from removing tuples that are still needed in
the standby.
4. Allow the query to continue, knowing that it will return wrong results.
I don't consider 4 to be an option. Option 3 has its own set of
drawbacks, as a standby can then cause bloat in the master, and in any
case we're not going to have it in this release. And then there's some
middle ground, like wait a while and then kill the query
(max_standby_delay > 0).
I don't see any way around the fact that when a tuple is removed, it's
gone and can't be accessed by queries. Either you don't remove it, or
you kill the query.
I think the max_standby_delay setting is fairly easy to explain. It
shouldn't be too hard for a DBA to set it correctly.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
