From: Rob Wultsch on
On Wed, May 5, 2010 at 9:32 PM, Robert Haas <robertmhaas(a)gmail.com> wrote:
> On Wed, May 5, 2010 at 11:50 PM, Bruce Momjian <bruce(a)momjian.us> wrote:
>> If someone wants to suggest that HS is useless if max_standby_delay
>> supports only boolean values, I am ready to suggest we remove HS as well
>> and head to 9.0 because that would suggest that HS itself is going to be
>> useless.
>
> I think HS is going to be a lot less useful than many people think, at
> least in 9.0.  But I think ripping out max_standby_delay will make it
> worse.
>
>> The code will not be thrown away;  we will bring it back for 9.1.
>
> If that's the case, then taking it out makes no sense.
>
<mysql dba troll>
I manage a bunch of different environments and I am pretty sure that
in any of them if the db started seemingly randomly killing queries I
would have application teams followed quickly by executives coming
after me with torches and pitchforks.

I can not imagine setting this value to anything other than a bool and
most of the time that bool would be -1. I would only be unleashing a
kill storm in utter desperation and I would probably need to explain
myself in detail after. Utter desperation means I am sure I am going
to have to do a impactful failover at any moment and need a slave
completely up to date NOW.

It is good to have the option to automatically cancel queries, but I
think it is a mistake to assume many people will use it.

What I would really need for instrumentation is the ability to
determine *easily* how much a slave is lagging in clock time.
</mysql dba troll>

--
Rob Wultsch
wultsch(a)gmail.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Simon Riggs on
On Thu, 2010-05-06 at 00:47 -0400, Robert Haas wrote:

> That just doesn't sound that bad to me, especially since the proposed
> alternative is:
>
> - Queries will get cancelled like crazy, period.
>
> Or else:
>
> - Replication can fall infinitely far behind and you can write a
> tedious and error-prone script to try to prevent it if you like.
>
> I think THAT is going to tarnish our reputation.

Yes, that will.

There is no consensus to remove max_standby_delay.

It could be improved with minor adjustments and it makes more sense to
allow a few of those, treating them as bugs.

--
Simon Riggs www.2ndQuadrant.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Simon Riggs on
On Wed, 2010-05-05 at 23:15 -0700, Rob Wultsch wrote:

> I manage a bunch of different environments and I am pretty sure that
> in any of them if the db started seemingly randomly killing queries I
> would have application teams followed quickly by executives coming
> after me with torches and pitchforks.

Fully understood and well argued, thanks for your input.

HS doesn't randomly kill queries and there are documented work-arounds
to control this behaviour.

Removing the parameter won't help the situation at all, it will make the
situation *worse* by removing control from where it's clearly needed and
removing all hope of making the HS feature work in practice. There is no
consensus to remove the parameter.

--
Simon Riggs www.2ndQuadrant.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Dimitri Fontaine on
Greg Smith <greg(a)2ndquadrant.com> writes:
> If you need a script that involves changing a server setting to do
> something, that translates into "you can't do that" for a typical DBA. The
> idea of a program regularly changing a server configuration setting on a
> production system is one you just can't sell. That makes this idea
> incredibly more difficult to use in the field than any of the workarounds
> that cope with the known max_standby_delay issues.

I still think that the best API we can do in a timely fashion for 9.0
is:

standby_conflict_winner = replay|queries

pg_pause_recovery() / pg_resume_recovery()

It seems to me those two functions are only exposing existing facilities
in the code, so that's more an API change that a new feature
inclusion. Of course I'm certainly wrong. But the code has already been
written.

I don't think we'll find any better to offer our users in the right time
frame. Now I'll try to step back and stop repeating myself in the void :)

Regards,
--
dim

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Florian Pflug on
On May 6, 2010, at 11:26 , Dimitri Fontaine wrote:
> Greg Smith <greg(a)2ndquadrant.com> writes:
>> If you need a script that involves changing a server setting to do
>> something, that translates into "you can't do that" for a typical DBA. The
>> idea of a program regularly changing a server configuration setting on a
>> production system is one you just can't sell. That makes this idea
>> incredibly more difficult to use in the field than any of the workarounds
>> that cope with the known max_standby_delay issues.
>
> I still think that the best API we can do in a timely fashion for 9.0
> is:
>
> standby_conflict_winner = replay|queries
>
> pg_pause_recovery() / pg_resume_recovery()
>
> It seems to me those two functions are only exposing existing facilities
> in the code, so that's more an API change that a new feature
> inclusion. Of course I'm certainly wrong. But the code has already been
> written.

If there was an additional SQL-callable function that returned the backends the recovery process is currently waiting for, plus one that reported that last timestamp seen in the WAL, than all those different cancellation policies could be implemented as daemons that monitor recovery and kill backends as needed, no?

That would allow people to experiment with different cancellation policies, and maybe shed some light on what the useful policies are in practice.

best regards,
Florian Pflug