Re: max_standby_delay considered harmful - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: max_standby_delay considered harmful
Date
Msg-id 4BE08A42.40008@agliodbs.com
Whole thread Raw
In response to Re: max_standby_delay considered harmful  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: max_standby_delay considered harmful
List pgsql-hackers
>>   AFAIK, Tom was proposing that the
>> pending recovery data would wait for max_standby_delay, total, then
>> cancel *all* queries which conflicted with it.  Now that we've talked
>> this out, though, I can see that this can still result in "mass cancel"
>> issues, just like the current max_standby_delay.   The main advantage I
>> can see to Tom's idea is that (presumably) it can be more discriminating
>> about which queries it cancels.
> 
> As I said to Stephen, this is exactly how it works already and wasn't
> what was proposed.

Well, it's not exactly how it works, as I understand it ... doesn't the
timer running out on the slave currently cancel *all* running queries
with old snapshots, regardless of what relations they touch?

> Before you posted, I submitted a patch on this thread to redefine
> max_standby_delay to depend upon the "application lag", as you've newly
> defined it here - though obviously I didn't call it that. That solves
> Tom's 3 issues. max_apply_delay might be technically more accurate term,
> though isn't sufficiently better parameter name as to be worth the
> change.

Yeah, that looks less complicated for admins.  Thanks.

> That patch doesn't implement his proposal, but that can be done as well
> as (though IMHO not instead of). Given that two people have already
> misunderstood what Tom proposed, and various people are saying we need
> only one, I'm getting less inclined to have that at all.

Given your clarification on the whole set of behaviors, I'm highly
dubious about the idea of implementing Tom's proposal when we're already
Beta 1.  It seems like a 9.1 thing.

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


pgsql-hackers by date:

Previous
From: Gurjeet Singh
Date:
Subject: GUCs that need restart
Next
From: "Kevin Grittner"
Date:
Subject: Re: GUCs that need restart