Re: Replication logging - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Replication logging
Date
Msg-id 1295432520.3282.8787.camel@ebony
Whole thread Raw
In response to Re: Replication logging  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Replication logging  (Bruce Momjian <bruce@momjian.us>)
List 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 by date:

Previous
From: Jan Urbański
Date:
Subject: Re: pl/python refactoring
Next
From: Pavel Stehule
Date:
Subject: ToDo: support for parameters in EXECUTE statement