| From: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(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-10 11:51:47 |
| Message-ID: | 20100510115147.GA14663@oak.highrise.ca |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
* Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> [100510 06:03]:
> A problem with using the name "max_standby_delay" for Tom's suggestion
> is that it sounds like a hard limit, which it isn't. But if we name it
> something like:
I'ld still rather an "if your killing something, make sure you kill
enough to get all the way current" behaviour, but that's just me....
I'm want to run my standbys in a always current mode... But if I decide
to play with a lagged HR, I really want to make sure there is some
mechanism to cap the lag, and the "cap" is something I can understand
and use to make a reasonable estimate as to when data I know is live on
the primary will be seen on the standby...
bonus points if it works similarly for archive recovery ;-)
a.
--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-05-10 11:53:52 | Re: max_standby_delay considered harmful |
| Previous Message | Kenichiro Tanaka | 2010-05-10 11:07:27 | make install fails due to "/bin/mkdir: missing operand" |