On Mon, Mar 25, 2013 at 1:14 PM, Simon Riggs wrote:
> On 25 March 2013 04:08, Michael Paquier wrote:
>
> > Feedback is warmly welcome.
>
> I'll look at this in the coming week.
>
Thanks.
--
Michael
On 25 March 2013 04:08, Michael Paquier wrote:
> Feedback is warmly welcome.
I'll look at this in the coming week.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Sat, Mar 9, 2013 at 1:20 PM, Greg Smith wrote:
> There are currently 20 "Needs Review" and 14 "Waiting on Author" things
> left in the queue, so it's not quite that there's no time left. There
> really isn't very much left to do on this. The rough consensus idea from
> before takes a while t
On 3/8/13 10:34 PM, Michael Paquier wrote:
This patch is still in the current commit fest. Any objections in
marking it as returned with feedback and put it in the next commit fest?
There are currently 20 "Needs Review" and 14 "Waiting on Author" things
left in the queue, so it's not quite tha
Michael Paquier escribió:
> On Wed, Mar 6, 2013 at 2:08 PM, Michael Paquier
> wrote:
> > Looks good to me too.
> > Based on the patch I already sent before, there are a couple of things
> > missing:
> > - There are no pg_ctl standby/recover commands implemented yet (no that
> > difficult to add)
>
On Wed, Mar 6, 2013 at 2:08 PM, Michael Paquier
wrote:
> Thanks for taking time in typing a complete summary of the situation. That
> really helps.
>
> On Mon, Mar 4, 2013 at 11:25 AM, Greg Smith wrote:
>
>> On 1/23/13 6:36 AM, Michael Paquier wrote:
>>
>>> The only problem I see is if the same p
Thanks for taking time in typing a complete summary of the situation. That
really helps.
On Mon, Mar 4, 2013 at 11:25 AM, Greg Smith wrote:
> On 1/23/13 6:36 AM, Michael Paquier wrote:
>
>> The only problem I see is if the same parameter is defined in
>> recovery.conf and postgresql.conf, is the
On Sun, Mar 3, 2013 at 9:25 PM, Greg Smith wrote:
> -Allow a "pg_ctl standby" and "pg_ctl recover" command that work similarly
> to "promote". This should slim down the work needed for the first
> replication setup people do.
> -Make it obvious when people try to use recovery.conf that it's not
>
On 1/23/13 6:36 AM, Michael Paquier wrote:
The only problem I see is if the same parameter is defined in recovery.conf and
postgresql.conf, is the priority given to recovery.conf?
This sort of thing is what dragged down the past work on this. I don't
really agree with the idea this thread is
On Sun, Jan 27, 2013 at 1:01 AM, Michael Paquier
wrote:
>> So... what happens when recovery ends? Do the settings loaded from
>> recovery.conf get reverted, or what?
>
> With current patch the settings are kept if set in postgresql.conf and
> discarded if they are loaded as GUC after a server res
On Sun, Jan 27, 2013 at 1:41 PM, Robert Haas wrote:
> On Sat, Jan 26, 2013 at 9:49 PM, Michael Paquier
> wrote:
> > On Sun, Jan 27, 2013 at 7:14 AM, Phil Sorber wrote:
> >>
> >> On Wed, Jan 23, 2013 at 6:36 AM, Michael Paquier
> >> wrote:
> >> >
> >> > On 2013/01/23, at 18:12, Simon Riggs wro
On Sat, Jan 26, 2013 at 9:49 PM, Michael Paquier
wrote:
> On Sun, Jan 27, 2013 at 7:14 AM, Phil Sorber wrote:
>>
>> On Wed, Jan 23, 2013 at 6:36 AM, Michael Paquier
>> wrote:
>> >
>> > On 2013/01/23, at 18:12, Simon Riggs wrote:
>> >
>> >> On 23 January 2013 04:49, Michael Paquier
>> >> wrote:
On Wed, Jan 23, 2013 at 6:36 AM, Michael Paquier
wrote:
>
> On 2013/01/23, at 18:12, Simon Riggs wrote:
>
>> On 23 January 2013 04:49, Michael Paquier wrote:
>>
>>> - recovery.conf is removed (no backward compatibility in this version of the
>>> patch)
>>
>> If you want to pursue that, you know
On 2013/01/23, at 18:12, Simon Riggs wrote:
> On 23 January 2013 04:49, Michael Paquier wrote:
>
>> - recovery.conf is removed (no backward compatibility in this version of the
>> patch)
>
> If you want to pursue that, you know where it leads. No, rebasing a
> rejected patch doesn't help, its
On 23 January 2013 04:49, Michael Paquier wrote:
> - recovery.conf is removed (no backward compatibility in this version of the
> patch)
If you want to pursue that, you know where it leads. No, rebasing a
rejected patch doesn't help, its just relighting a fire that shouldn't
ever have been lit.
> - if you want to trigger a recovery at promotion or have the recovery
> parameters read on slave at startup, you need to create a file called
> recovery.trigger in PGDATA. (something like "touch recovery.conf" is
> enough). Once recovery is done, recovery.trigger is changed to
> recovery.done.
On Wed, Jan 23, 2013 at 1:49 PM, Michael Paquier
wrote:
> I found that support for pg_basebackup -R was in the old patch, and I
> haven't done anything for that yet.
>
Sorry, I meant that pg_basebackup -R support was NOT in the old patch, and
I haven't done anything about that.
Typed too quickly..
On 21 January 2013 23:23, Michael Paquier wrote:
> It is an 17-month-old-patch, so of course it does not apply on master.
> However before taking any actions, I would like to know the following:
> - Simon, are you planning to update this patch?
It's on my list, but not at the front to the queue.
Le mardi 22 janvier 2013 01:54:50, Michael Paquier a écrit :
> On Tue, Jan 22, 2013 at 9:27 AM, Robert Haas wrote:
>
> > On Mon, Jan 21, 2013 at 6:23 PM, Michael Paquier
> > wrote:
> > > Yes, that is one of the most important patches in the list, and I could
> > put
> > > some effort in it for e
On Tue, Jan 22, 2013 at 9:27 AM, Robert Haas wrote:
> On Mon, Jan 21, 2013 at 6:23 PM, Michael Paquier
> 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 elaborat
On Mon, Jan 21, 2013 at 6:23 PM, Michael Paquier
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 impor
On Tue, Jan 22, 2013 at 1:11 AM, Phil Sorber wrote:
> On Fri, Dec 21, 2012 at 2:46 PM, Bruce Momjian 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 fil
On Fri, Dec 21, 2012 at 2:46 PM, Bruce Momjian 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
On 21 December 2012 19:46, Bruce Momjian 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 n
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 hav
25 matches
Mail list logo
