Re: Hot Standby (v9d)
От | Greg Stark |
---|---|
Тема | Re: Hot Standby (v9d) |
Дата | |
Msg-id | 5C2E8A03-66B2-45CE-A38E-D9CC7A520C5F@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Hot Standby (v9d) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Put another way: your characterization is no more true than claiming there's no "safe" setting for statement_timeout since a large value means clog could overflow your disk and your tables could bloat. (I note we default statement_timeout to off though) -- Greg On 28 Jan 2009, at 19:56, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: >> On Wed, 2009-01-28 at 19:27 +0000, Simon Riggs wrote: >>> On Wed, 2009-01-28 at 18:55 +0000, Gregory Stark wrote: >>>> I still *strongly* feel the default has to be the >>>> non-destructive conservative -1. >>> >>> I don't. Primarily, we must support high availability. It is much >>> better >>> if we get people saying "I get my queries cancelled" and we say >>> RTFM and >>> change parameter X, than if people say "my failover was 12 hours >>> behind >>> when I needed it to be 10 seconds behind and I lost a $1 million >>> because >>> of downtime of Postgres" and we say RTFM and change parameter X. > >> If the person was stupid enough to configure it for such as thing >> they >> deserve to the lose the money. > > Well, those unexpectedly cancelled queries could have represented > critical functionality too. I think this argument calls the entire > approach into question. If there is no safe setting for the parameter > then we need to find a way to not have the parameter. > > regards, tom lane
В списке pgsql-hackers по дате отправления: