On Tue, Apr 20, 2010 at 5:53 AM, Fujii Masao wrote:
> On Tue, Apr 20, 2010 at 9:55 AM, Robert Haas wrote:
>>> How about wal_keep_segments?
>
> +1
>
>> Here's the patch.
>
> Seems OK.
Thanks, committed.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
On Tue, Apr 20, 2010 at 9:55 AM, Robert Haas wrote:
>> How about wal_keep_segments?
+1
> Here's the patch.
Seems OK.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
On Fri, Apr 16, 2010 at 9:47 PM, Robert Haas wrote:
> On Thu, Apr 15, 2010 at 6:13 PM, Robert Haas wrote:
>> On Thu, Apr 15, 2010 at 2:54 AM, Heikki Linnakangas
>> wrote:
>>> Robert Haas wrote:
I've realized another problem with this patch. standby_keep_segments
only controls the numb
On Thu, Apr 15, 2010 at 6:13 PM, Robert Haas wrote:
> On Thu, Apr 15, 2010 at 2:54 AM, Heikki Linnakangas
> wrote:
>> Robert Haas wrote:
>>> I've realized another problem with this patch. standby_keep_segments
>>> only controls the number of segments that we keep around for purposes
>>> of strea
On Thu, Apr 15, 2010 at 2:54 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> I've realized another problem with this patch. standby_keep_segments
>> only controls the number of segments that we keep around for purposes
>> of streaming: it doesn't affect archiving at all. And of course, a
>
Robert Haas escribió:
> In the department of minor nits, I also don't like the fact that the
> GUC is called standby_keep_segments and the variable is called
> StandbySegments. If we really have to capitalize them differently, we
> should at least make it StandbyKeepSegments, but personally I thi
Robert Haas wrote:
> I've realized another problem with this patch. standby_keep_segments
> only controls the number of segments that we keep around for purposes
> of streaming: it doesn't affect archiving at all. And of course, a
> standby server based on archiving is every bit as much of a stan
On Tue, Apr 13, 2010 at 11:56 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> On Mon, Apr 12, 2010 at 6:41 AM, Heikki Linnakangas
>> wrote:
Why is standby_keep_segments used even if max_wal_senders is zero?
In that case, ISTM we don't need to keep any WAL files in pg_xlog
for
Robert Haas wrote:
> On Mon, Apr 12, 2010 at 6:41 AM, Heikki Linnakangas
> wrote:
>>> Why is standby_keep_segments used even if max_wal_senders is zero?
>>> In that case, ISTM we don't need to keep any WAL files in pg_xlog
>>> for the standby.
>> True. I don't think we should second guess the admi
On Mon, Apr 12, 2010 at 6:41 AM, Heikki Linnakangas
wrote:
>> Why is standby_keep_segments used even if max_wal_senders is zero?
>> In that case, ISTM we don't need to keep any WAL files in pg_xlog
>> for the standby.
>
> True. I don't think we should second guess the admin on that, though.
> Perh
On Mon, Apr 12, 2010 at 7:41 PM, Heikki Linnakangas
wrote:
>> We should remove the document "25.2.5.2. Monitoring"?
>
> I updated it to no longer claim that the primary can run out of disk
> space because of a hung WAL sender. The information about calculating
> the lag between primary and standby
Fujii Masao wrote:
> doc/src/sgml/config.sgml
> -archival or to recover from a checkpoint. If standby_keep_segments
> +archival or to recover from a checkpoint. If
> standby_keep_segments
>
> The word "standby_keep_segments" always needs the tag, I think.
Thanks, fixed.
> We sho
Thanks for the great patch! I apologize for leaving the issue
half-finished for long time :(
On Wed, Apr 7, 2010 at 7:02 PM, Heikki Linnakangas
wrote:
> In your version of this patch, the default was still the current
> behavior where the primary retains WAL files that are still needed by
> conne
On Wed, Apr 7, 2010 at 6:02 AM, Heikki Linnakangas
wrote:
> This task has been languishing for a long time, so I took a shot at it.
> I took the approach I suggested before, keeping a variable in shared
> memory to track the latest removed WAL segment. After walsender has read
> a bunch of WAL rec
This task has been languishing for a long time, so I took a shot at it.
I took the approach I suggested before, keeping a variable in shared
memory to track the latest removed WAL segment. After walsender has read
a bunch of WAL records from a WAL file, it checks that what it read is
after the late
Thanks for the review! And, sorry for the delay.
On Thu, Jan 21, 2010 at 11:10 PM, Heikki Linnakangas
wrote:
> I don't think we should do the check XLogWrite(). There's really no
> reason to kill the standby connections before the next checkpoint, when
> the old WAL files are recycled. XLogWrite(
Fujii Masao wrote:
> If the primary has a connected standby, the WAL files required for
> the standby cannot be deleted. So if it has fallen too far behind
> for some reasons, a disk full failure might occur on the primary.
> This is one of the problems that should be fixed for v9.0.
>
> We can co
17 matches
Mail list logo
