Re: max_standby_delay considered harmful

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: max_standby_delay considered harmful
Date: 2010-05-05 22:29:33
Message-ID: 4BE1F14D.4020202@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki, all,

> There's currently three ways to set max_standby_delay:
>
> max_standby_delay = -1 # Query wins
> max_standby_delay = 0 # Recovery wins
> max_standby_delay > X # Query wins until lag > X.
>
> As Tom points out, the 3rd option has all sorts of problems. I very much
> like the behavior that max_standby_delay tries to accomplish, but I have
> to agree that it's not very reliable as it is.

Wow, thanks for the summary. Based on that, I take back what I said to
Greg.

Because I think getting 9.0 out *on time* is more important than any of
these issues, I'm revising my opinion to be more in line with Greg
Smith. So, proposed path forwards.

(1) We work on getting the specific bugs Tom reported fixed.
(2) max_standby_delay default is 0
(3) documentation covers setting it to an integer, but warns extensively
about the required sysadminning and query cancel. As in "for advanced
users only".
(4) discussion of other synch methods gets shifted to 9.0

Ultimately, I think we'll be going to something lock-based like what Tom
suggested. However, I don't think that's doable without delaying 9.0
for 6 months, and I think that would be much worse than any current bug
with 9.0.

No matter how much we tinker with HS/SR, it's not going to be
bulletproof until 9.1. Or, more likely, 9.2.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-05-05 23:18:56 Re: max_standby_delay considered harmful
Previous Message Mark Kirkwood 2010-05-05 21:48:18 Re: Reg: SQL Query for Postgres 8.4.3