On 01/22/2013 06:43 AM, Noah Misch wrote:
> This patch was in Needs Review status, but you committed it on 2013-01-17. I
> have marked it as such in the CF app.
Thankyou. There's a lot to keep up with :S
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On Tue, Jan 22, 2013 at 8:33 AM, Dimitri Fontaine
wrote:
> Heikki Linnakangas writes:
>> You might not want to keep a copy of the whole data directory around, as you
>> have to in a cascading standby. I can see value in a separate WAL proxy
>> software, especially if it's integrated into a larger
Heikki Linnakangas writes:
> You might not want to keep a copy of the whole data directory around, as you
> have to in a cascading standby. I can see value in a separate WAL proxy
> software, especially if it's integrated into a larger backup manager program
> like barman or wal-e.
+1
I somehow
On 22.01.2013 15:02, Dimitri Fontaine wrote:
Phil Sorber writes:
What do you think about the idea of a full WAL proxy? Probably not for
9.3 at this point though.
I was thinking that a WAL proxy nowadays is called a cascading standby
with local archiving enabled. I'm not sure why you would wan
Phil Sorber writes:
> What do you think about the idea of a full WAL proxy? Probably not for
> 9.3 at this point though.
I was thinking that a WAL proxy nowadays is called a cascading standby
with local archiving enabled. I'm not sure why you would want to trust
your archiving and WAL relaying to
This patch was in Needs Review status, but you committed it on 2013-01-17. I
have marked it as such in the CF app.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jan 18, 2013 at 7:55 AM, Heikki Linnakangas
wrote:
> On 18.01.2013 06:38, Phil Sorber wrote:
>> Is it possible to re-use walreceiver code from the backend?
>>
>> I was thinking that it would actually be very useful to have the whole
>> replication functionality modularized and in a standal
On 18.01.2013 06:38, Phil Sorber wrote:
On Tue, Jan 15, 2013 at 9:05 AM, Heikki Linnakangas
wrote:
Now that a standby server can follow timeline switches through streaming
replication, we should do teach pg_receivexlog to do the same. Patch
attached.
Is it possible to re-use walreceiver code
On Tue, Jan 15, 2013 at 9:05 AM, Heikki Linnakangas
wrote:
> Now that a standby server can follow timeline switches through streaming
> replication, we should do teach pg_receivexlog to do the same. Patch
> attached.
Is it possible to re-use walreceiver code from the backend?
I was thinking that
Robert Haas escribió:
> Actually, I'm really glad to see all the work you've done to improve
> the way that some of these scenarios work and eliminate various bugs
> and other surprising failure modes over the last couple of months.
> It's great stuff.
+1
--
Álvaro Herrerahttp:/
On Thu, Jan 17, 2013 at 9:59 AM, Heikki Linnakangas
wrote:
> The scenario I described is that you screwed up your failover environment,
> and end up with a split-brain situation by accident. The DBA certainly needs
> to be involved to recover from that.
OK, I agree, but I still think a lot of DBA
On 17.01.2013 16:56, Robert Haas wrote:
On Wed, Jan 16, 2013 at 11:08 AM, Heikki Linnakangas
wrote:
I'd prefer to leave the .partial suffix in place, as the segment really
isn't complete. It doesn't make a difference when you recover to the latest
timeline, but if you have a more complicated s
On Wed, Jan 16, 2013 at 11:08 AM, Heikki Linnakangas
wrote:
> I'd prefer to leave the .partial suffix in place, as the segment really
> isn't complete. It doesn't make a difference when you recover to the latest
> timeline, but if you have a more complicated scenario with multiple
> timelines that
Fujii Masao writes:
> Thanks for elaborating the reason why .partial suffix should be kept.
> I agree that keeping the .partial suffix would be safer.
+1 to both points. So +2 I guess :)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
S
On Thu, Jan 17, 2013 at 1:08 AM, Heikki Linnakangas
wrote:
> On 15.01.2013 20:22, Fujii Masao wrote:
>>
>> On Tue, Jan 15, 2013 at 11:05 PM, Heikki Linnakangas
>> wrote:
>>>
>>> Now that a standby server can follow timeline switches through streaming
>>> replication, we should do teach pg_receiv
On 15.01.2013 20:22, Fujii Masao wrote:
On Tue, Jan 15, 2013 at 11:05 PM, Heikki Linnakangas
wrote:
Now that a standby server can follow timeline switches through streaming
replication, we should do teach pg_receivexlog to do the same. Patch
attached.
I made one change to the way START_STREAM
On Tue, Jan 15, 2013 at 11:05 PM, Heikki Linnakangas
wrote:
> Now that a standby server can follow timeline switches through streaming
> replication, we should do teach pg_receivexlog to do the same. Patch
> attached.
>
> I made one change to the way START_STREAMING command works, to better
> supp
Now that a standby server can follow timeline switches through streaming
replication, we should do teach pg_receivexlog to do the same. Patch
attached.
I made one change to the way START_STREAMING command works, to better
support this. When a standby server reaches the timeline it's streaming
18 matches
Mail list logo
