On Tue, Jul 19, 2011 at 1:38 PM, Fujii Masao wrote:
> On Tue, Jul 19, 2011 at 9:09 PM, Simon Riggs wrote:
>> On Tue, Jul 19, 2011 at 12:19 PM, Fujii Masao
>> wrote:
>>
>>> So we would still have some code to change.
>>
>> Sigh, yes, of course.
>>
>> The question was whether there is any reason w
On Tue, Jul 19, 2011 at 9:09 PM, Simon Riggs wrote:
> On Tue, Jul 19, 2011 at 12:19 PM, Fujii Masao wrote:
>
>> So we would still have some code to change.
>
> Sigh, yes, of course.
>
> The question was whether there is any reason we need to disallow cascading?
No, at least I have no clear reaso
On Tue, Jul 19, 2011 at 12:19 PM, Fujii Masao wrote:
> So we would still have some code to change.
Sigh, yes, of course.
The question was whether there is any reason we need to disallow cascading?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Supp
On Tue, Jul 19, 2011 at 5:58 PM, Simon Riggs wrote:
> On Mon, Jul 11, 2011 at 7:28 AM, Fujii Masao wrote:
>
>> Attached is the updated version which addresses all the issues raised by
>> Simon.
>
> Is there any reason why we disallow cascading unless hot standby is enabled?
>
> ISTM we can just a
On Mon, Jul 11, 2011 at 7:28 AM, Fujii Masao wrote:
> Attached is the updated version which addresses all the issues raised by
> Simon.
Is there any reason why we disallow cascading unless hot standby is enabled?
ISTM we can just alter the postmaster path for walsenders, patch attached.
Some p
On Mon, Jul 11, 2011 at 10:26 AM, Fujii Masao wrote:
> On Mon, Jul 11, 2011 at 3:30 AM, Josh Berkus wrote:
>> Do you think you'll submit a new version of the patch this commitfest?
>
> Yes. I'm now updating the patch according to Simon's comments.
> I will submit it today.
Attached is the update
On Mon, Jul 11, 2011 at 3:30 AM, Josh Berkus wrote:
> Fujii,
>
>> In the current scheme we restart archiving from the last restartpoint,
>> which exists only on the archive. This new patch improves upon this by
>> keeping the most recent files locally, so we are less expose in the
>> case of archi
Fujii,
> In the current scheme we restart archiving from the last restartpoint,
> which exists only on the archive. This new patch improves upon this by
> keeping the most recent files locally, so we are less expose in the
> case of archive unavailability. So this patch already improves things
> a
On Wed, Jul 6, 2011 at 12:27 PM, Fujii Masao wrote:
> On Wed, Jul 6, 2011 at 4:53 PM, Fujii Masao wrote:
>> On Wed, Jul 6, 2011 at 2:44 PM, Simon Riggs wrote:
1. De-archive the file to RECOVERYXLOG
2. If RECOVERYXLOG is valid, remove a pre-existing one and rename
RECOVERYXLOG t
On Wed, Jul 6, 2011 at 4:53 PM, Fujii Masao wrote:
> On Wed, Jul 6, 2011 at 2:44 PM, Simon Riggs wrote:
>>> 1. De-archive the file to RECOVERYXLOG
>>> 2. If RECOVERYXLOG is valid, remove a pre-existing one and rename
>>> RECOVERYXLOG to the correct name
>>> 3. Replay the file with the correct
On Wed, Jul 6, 2011 at 8:53 AM, Fujii Masao wrote:
>>> What about outputing something like the following message in that case?
>>>
>>> if ("walsender receives SIGUSR2")
>>> ereport(LOG, "terminating walsender process due to
>>> administrator command");
>>
>> ...which doesn't explain the
On Wed, Jul 6, 2011 at 2:44 PM, Simon Riggs wrote:
>> 1. De-archive the file to RECOVERYXLOG
>> 2. If RECOVERYXLOG is valid, remove a pre-existing one and rename
>> RECOVERYXLOG to the correct name
>> 3. Replay the file with the correct name
>
> Yes please, that makes sense.
Will do.
>>> Thos
On Wed, Jul 6, 2011 at 2:13 AM, Fujii Masao wrote:
>> IMHO it's time to get rid of RECOVERYXLOG as an initial target for
>> de-archived files. That made sense once, but now we have streaming it
>> makes more sense for us to de-archive straight onto the correct file
>> name and let the file be cle
On Tue, Jul 5, 2011 at 8:08 PM, Simon Riggs wrote:
> Now for the rest of the review...
Thanks!
> I'd rather not include another chunk of code related to
> wal_keep_segments. The existing code in CreateCheckPoint() should be
> refactored so that we call the same code from both CreateCheckPoint()
On Tue, Jul 5, 2011 at 4:34 AM, Fujii Masao wrote:
> On Mon, Jul 4, 2011 at 6:24 PM, Simon Riggs wrote:
>> On Tue, Jun 14, 2011 at 6:08 AM, Fujii Masao wrote:
>>
The standby must not accept replication connection from that standby
itself.
Otherwise, since any new WAL data would n
On Mon, Jul 4, 2011 at 6:24 PM, Simon Riggs wrote:
> On Tue, Jun 14, 2011 at 6:08 AM, Fujii Masao wrote:
>
>>> The standby must not accept replication connection from that standby itself.
>>> Otherwise, since any new WAL data would not appear in that standby,
>>> replication cannot advance any mo
On Tue, Jun 14, 2011 at 6:08 AM, Fujii Masao wrote:
>> The standby must not accept replication connection from that standby itself.
>> Otherwise, since any new WAL data would not appear in that standby,
>> replication cannot advance any more. As a safeguard against this, I
>> introduced
>> new I
Hi,
I'd like to propose cascade replication feature (i.e., allow the
standby to accept
replication connection from another standby) for 9.2. This feature is useful to
reduce the overhead of the master since by using that we can decrease the
number of standbys directly connecting to the master.
I
18 matches
Mail list logo
