From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: max_standby_delay considered harmful |
Date: | 2010-05-06 09:26:30 |
Message-ID: | 87ljbxjs8p.fsf@hi-media-techno.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Smith <greg(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2010-05-06 09:31:37 | Re: Partitioning/inherited tables vs FKs |
Previous Message | Boszormenyi Zoltan | 2010-05-06 08:52:42 | Partitioning/inherited tables vs FKs |