Re: Request for vote to move forward with recovery.conf overhaul - Mailing list pgsql-hackers

From Phil Sorber
Subject Re: Request for vote to move forward with recovery.conf overhaul
Date
Msg-id CADAkt-iw+bw=PzjP3X7ZAo-zimb-cdD8FYRGeF3PT_VJZa1QBA@mail.gmail.com
Whole thread Raw
In response to Request for vote to move forward with recovery.conf overhaul  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Request for vote to move forward with recovery.conf overhaul
List pgsql-hackers
On Fri, Dec 21, 2012 at 2:46 PM, Bruce Momjian <bruce@momjian.us> wrote:
> There has been discussion in the past of removing or significantly
> changing the way streaming replication/point-in-time-recovery (PITR) is
> setup in Postgres.  Currently the file recovery.conf is used, but that
> was designed for PITR and does not serve streaming replication well.
>
> This all should have been overhauled when streaming replication was
> added in 2010 in Postgres 9.0.  However, time constraints and concern
> about backward compatibility has hampered this overhaul.
>
> At this point, backward compatibility seems to be hampering our ability
> to move forward.  I would like a vote that supports creation of a new
> method for setting up streaming replication/point-in-time-recovery,
> where backward compatibility is considered only where it is minimally
> invasive.
>
> --
>   Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>   EnterpriseDB                             http://enterprisedb.com
>
>   + It's impossible for everything to be true. +
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

+1

I seemed to have lost track of the thread that this spawned out of. Is
there a coherent plan for a way forward at this point? Last I recall
it was Simon's plan vs Bruce's plan. I also seem to recall there was a
patch out there too. I think it's even in the commitfest waiting on
author.

/me searches

Here:
https://commitfest.postgresql.org/action/patch_view?id=1026

Perhaps we can get the two plans enumerated, vote, and then get a patch out?

I'd really like to see this in 9.3, but not sure if that ship has
sailed for this feature or not.

Thanks.



pgsql-hackers by date:

Previous
From: Amit kapila
Date:
Subject: Re: Review: Patch to compute Max LSN of Data Pages
Next
From: Steve Singer
Date:
Subject: Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)