Re: Replication logging

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Replication logging
Дата
Msg-id 1295432520.3282.8787.camel@ebony
обсуждение исходный текст
Ответ на Re: Replication logging  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Replication logging  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Tue, 2011-01-18 at 10:57 -0500, Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > Is there *any* usecase for setting them differently though?
> 
> I can't believe we're still engaged in painting this bikeshed.  Let's
> just control it off log_connections and have done.

Yes, this is a waste of time. Leave it as is because its there for a
very good reason, as Robert already explained.

The code was put in explicitly because debugging replication connections
is quite important and prior to that addition, wasn't easy. It's a very
separate thing from logging the hundreds/thousands of other connections
on the system.

I don't really care about neatness of code, or neatness of parameters. I
want to be able to confirm the details of the connection.
pg_stat_replication is dynamic, not a historical record of connections
and reconnections.

How else will you diagnose an erratic network, or an accidental change
of authority? Replication is so important it isn't worth tidying away a
couple of lines of log. My objective is to make replication work, not to
reduce the size of the average log file by 1 or 2 lines.

I'm particularly concerned that people make such changes too quickly.
There are many things in this area of code that need changing, but also
many more that do not. If we are to move forwards we need to avoid going
one step forwards, one step back.

-- Simon Riggs           http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jan Urbański
Дата:
Сообщение: Re: pl/python refactoring
Следующее
От: Pavel Stehule
Дата:
Сообщение: ToDo: support for parameters in EXECUTE statement