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
Hi,
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 cope with that case by caref
18 matches
Mail list logo
