Re: Replication logging

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Replication logging
Date: 2011-01-19 17:15:50
Message-ID: 201101191715.p0JHFoI04402@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Simon Riggs wrote:
> >> 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.
>
> > There were enough people who wanted a change that we went ahead and did
> > it --- if there was lack of agreement, we would have delayed longer.
>
> The real reason why we changed this is that nobody (except Simon) sees
> a situation where unconditional logging of successful replication
> connections is especially helpful. If you were trying to diagnose a
> problem you would more likely need to know about *failed* connections,
> but the code that was in there didn't provide that. At least not unless
> you turned on log_connections ...

Yep.

Simon, I understand you being disappointed you could not champion your
cause during the discussion, but you can still try to sway people that
the original code was appropriate.

Based on the feedback from the group, it seemed unlikely you would be
able to sway a significant number of people so we just went ahead and
made the change.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-01-19 17:20:00 Re: pl/python refactoring
Previous Message Tom Lane 2011-01-19 17:10:16 Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql