Thread: trace_recovery_messages
Hi, We should make trace_recovery_messages available only when the WAL_DEBUG macro was defined? Currently it's always available, so the standby seems to call elog() too frequently. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
Fujii Masao <masao.fujii@gmail.com> writes: > We should make trace_recovery_messages available only when > the WAL_DEBUG macro was defined? No, because it's used in a lot of other contexts besides that. > Currently it's always > available, so the standby seems to call elog() too frequently. Where? I don't see very many messages that would actually get emitted at the default setting of the parameter. regards, tom lane
On Fri, Jun 18, 2010 at 2:48 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Fujii Masao <masao.fujii@gmail.com> writes: >> We should make trace_recovery_messages available only when >> the WAL_DEBUG macro was defined? > > No, because it's used in a lot of other contexts besides that. > >> Currently it's always >> available, so the standby seems to call elog() too frequently. > > Where? I don't see very many messages that would actually get emitted > at the default setting of the parameter. Yes. I was just concerned that frequent calls themselves may increase the overhead. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
On Fri, 2010-06-18 at 10:20 +0900, Fujii Masao wrote: > On Fri, Jun 18, 2010 at 2:48 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Fujii Masao <masao.fujii@gmail.com> writes: > >> We should make trace_recovery_messages available only when > >> the WAL_DEBUG macro was defined? > > > > No, because it's used in a lot of other contexts besides that. > > > >> Currently it's always > >> available, so the standby seems to call elog() too frequently. > > > > Where? I don't see very many messages that would actually get emitted > > at the default setting of the parameter. > > Yes. I was just concerned that frequent calls themselves may increase > the overhead. Please share your oprofile output so we can see the problem. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services