Re: Stefan's bug (was: max_standby_delay considered harmful)
От | Robert Haas |
---|---|
Тема | Re: Stefan's bug (was: max_standby_delay considered harmful) |
Дата | |
Msg-id | AANLkTikNSTliNzAoObAR-cUflQHCGmVgjYFYfzyVdLP2@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Stefan's bug (was: max_standby_delay considered harmful) (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Stefan's bug (was: max_standby_delay considered
harmful)
|
Список | pgsql-hackers |
On Wed, May 19, 2010 at 8:49 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Wed, 2010-05-19 at 08:21 -0400, Tom Lane wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >> > On Wed, May 19, 2010 at 1:47 AM, Fujii Masao <masao.fujii@gmail.com> wrote: >> >> Yes, but I prefer XLogCtl->SharedRecoveryInProgress, which is the almost >> >> same indicator as the boolean you suggested. Thought? >> >> > It feels cleaner and simpler to me to use the information that the >> > postmaster already collects rather than having it take locks and check >> > shared memory, but I might be wrong. Why do you prefer doing it that >> > way? >> >> The postmaster must absolutely not take locks (once there are competing >> processes). This is non negotiable from a system robustness standpoint. > > Masao has not proposed this, in fact his proposal was to deliberately > avoid do so. > > I proposed using the state recorded in xlog.c rather than attempting to > duplicate that with a second boolean in postmaster because that seems > likely to be more buggy. Well then how are we reading XLogCtl? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: