Re: Request for vote to move forward with recovery.conf overhaul

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Phil Sorber <phil(at)omniti(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Request for vote to move forward with recovery.conf overhaul
Date: 2013-01-22 00:54:50
Message-ID: CAB7nPqT45hh9oXH-8bSZtTwQ0+U+=-49wdhK+U4npn50EJ_E-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 22, 2013 at 9:27 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Jan 21, 2013 at 6:23 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
> > Yes, that is one of the most important patches in the list, and I could
> put
> > some effort in it for either review or coding.
>
> I think it would be great if you could elaborate on your reasons for
> feeling that this patch is particularly important.
>
Sure. recovery.conf has been initially created for PITR management, but
since 9.0 and the introduction of streaming replication it is being used
for too many things that it was first targeting for, like now it can be
used to define where a slave can connect to a root node, fetch the
archives, etc. I am seeing for a long time on hackers (2010?) that postgres
should make the move on giving up recovery.conf and merge it with
postgresql.conf.

I didn't know about the existence of a patch aimed to merge the parameters
of postgresql.conf and recovery.conf, and, just by looking at the patch,
half of the work looks to be already done. I thought it might be worth to
at least update the patch or provide some feedback.

I agree that this might break backward-compatibility and that it would be
more suited for a 10.0(?), but as 9.3 development is already close to its
end, progressing on this discussion and decide whether this could be
shipped for 9.3 or later release is important. If it is decided to give up
on this feature, well let's do that later. If it is worth the shot, let's
put some effort for it.
--
Michael Paquier
http://michael.otacoo.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dickson S. Guedes 2013-01-22 01:17:20 Re: Prepared statements fail after schema changes with surprising error
Previous Message Peter Geoghegan 2013-01-22 00:40:41 Re: Prepared statements fail after schema changes with surprising error