Re: max_standby_delay considered harmful
От | Simon Riggs |
---|---|
Тема | Re: max_standby_delay considered harmful |
Дата | |
Msg-id | 1273678093.308.856.camel@ebony обсуждение исходный текст |
Ответ на | Re: max_standby_delay considered harmful (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: max_standby_delay considered harmful
Re: max_standby_delay considered harmful |
Список | pgsql-hackers |
On Wed, 2010-05-12 at 14:18 +0100, Simon Riggs wrote: > On Wed, 2010-05-12 at 08:52 -0400, Robert Haas wrote: > > On Wed, May 12, 2010 at 7:26 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > > > On Wed, 2010-05-12 at 07:10 -0400, Robert Haas wrote: > > > > > >> I'm not sure what to make of this. Sometimes not shutting down > > >> doesn't sound like a feature to me. > > > > > > It acts exactly the same in recovery as in normal running. It is not a > > > special feature of recovery at all, bug or otherwise. > > > > Simon, that doesn't make any sense. We are talking about a backend > > getting stuck forever on an exclusive lock that is held by the startup > > process and which will never be released (for example, because the > > master has shut down and no more WAL can be obtained for replay). The > > startup process does not hold locks in normal operation. > > When I test it, startup process holding a lock does not prevent shutdown > of a standby. > > I'd be happy to see your test case showing a bug exists and that the > behaviour differs from normal running. Let me put this differently: I accept that Stefan has reported a problem. Neither Tom nor myself can reproduce the problem. I've re-run Stefan's test case and restarted the server more than 400 times now without any issue. I re-read your post where you gave what you yourself called "uninformed speculation". There's no real polite way to say it, but yes your speculation does appear to be uninformed, since it is incorrect. Reasons would be not least that Stefan's tests don't actually send any locks to the standby anyway (!), but even if they did your speculation as to the cause is still all wrong, as explained. There is no evidence to link this behaviour with HS, as yet, and you should be considering the possibility the problem lies elsewhere, especially since it could be code you committed that is at fault. -- Simon Riggs www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: