Robert Haas wrote:
> On Sat, May 8, 2010 at 10:40 PM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> Uh, did we decide that 'wal_keep_segments' was the best name for this
> >> GUC setting? ?I know we shipped beta1 using that name.
> >
> > I thought min_wal_segments was a reasonable proposal, but
On Sat, 2010-05-08 at 23:55 -0400, Robert Haas wrote:
> On Sat, May 8, 2010 at 10:40 PM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> Uh, did we decide that 'wal_keep_segments' was the best name for this
> >> GUC setting? I know we shipped beta1 using that name.
> >
> > I thought min_wal_segme
On Sat, May 8, 2010 at 10:40 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Uh, did we decide that 'wal_keep_segments' was the best name for this
>> GUC setting? I know we shipped beta1 using that name.
>
> I thought min_wal_segments was a reasonable proposal, but it wasn't
> clear if there was
Bruce Momjian writes:
> Uh, did we decide that 'wal_keep_segments' was the best name for this
> GUC setting? I know we shipped beta1 using that name.
I thought min_wal_segments was a reasonable proposal, but it wasn't
clear if there was consensus or not.
regards, tom lan
Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Fri, 2010-04-30 at 12:22 -0400, Bruce Momjian wrote:
> > > >
> > > > (wal_keep_segments can be changed without restarting, right?)
> > >
> > > Should we allow -1 to mean "keep all segments"?
> >
> > Why is that not called "max_wal_segments"? wal_k
> It's really both of those things, so we could call it
> wal_min_keep_segments, but I think an even better name would be
> bikeshed_segments.
Speaking from my UI perspective, I don't think users will care what we
call it.
--
-- Josh Berkus
On Mon, May 3, 2010 at 2:54 PM, Kevin Grittner
wrote:
> Simon Riggs wrote:
>> On Fri, 2010-04-30 at 13:41 -0500, Kevin Grittner wrote:
>
>>> Surely it would confuse people to see they have fewer than
>>> min_wal_segments WAL segments.
>>
>> That does sound like a reasonable argument, though it al
Simon Riggs wrote:
> On Fri, 2010-04-30 at 13:41 -0500, Kevin Grittner wrote:
>> Surely it would confuse people to see they have fewer than
>> min_wal_segments WAL segments.
>
> That does sound like a reasonable argument, though it also applies
> to wal_keep_segments, so isn't an argument eithe
On Fri, 2010-04-30 at 13:41 -0500, Kevin Grittner wrote:
> Heikki Linnakangas wrote:
>
> > Yeah, min_wal_segments or something would make sense.
>
> Surely it would confuse people to see they have fewer than
> min_wal_segments WAL segments.
That does sound like a reasonable argument, though i
Heikki Linnakangas wrote:
> Kevin Grittner wrote:
>> Surely it would confuse people to see they have fewer than
>> min_wal_segments WAL segments.
>
> they wouldn't see that, that's the point of the setting.
I was thinking, in particular, about beginners poking around to see
how things look afte
Kevin Grittner wrote:
> Heikki Linnakangas wrote:
>
>> Yeah, min_wal_segments or something would make sense.
>
> Surely it would confuse people to see they have fewer than
> min_wal_segments WAL segments.
Umm, they wouldn't see that, that's the point of the setting. The
segments are not remov
On Fri, 2010-04-30 at 14:42 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs wrote:
> >> Why is that not called "max_wal_segments"? wal_keep_segments sounds like
> >> its been through Google translate.
>
> > Because it's not a maximum?
>
> Indeed. I
Alvaro Herrera writes:
> Bruce Momjian escribió:
>> Which is where my 'wal_keep_segments = -1' idea came from.
> Are you suggesting that -1 should mean "keep all segments that fit on
> disk, but if creating a new segment fails with ENOSPC, recycle the
> oldest one"?
No, keep means keep. Even if
Michael Tharp wrote:
> On 04/30/2010 01:53 PM, Robert Haas wrote:
>>
>> Well, one of us is. Why would you want to retain all of your WAL logs
>> in pg_xlog forever?
>
> To create or re-synchronize SR slaves, one could change
> wal_keep_segments to -1, run a backup, wait for the slaves to catch up
Bruce Momjian escribió:
> Which is where my 'wal_keep_segments = -1' idea came from.
Are you suggesting that -1 should mean "keep all segments that fit on
disk, but if creating a new segment fails with ENOSPC, recycle the
oldest one"?
--
Alvaro Herrerahttp://www.
Heikki Linnakangas writes:
> Bruce Momjian wrote:
>> Should we allow -1 to mean "keep all segments"?
> Umm, you can't keep all segments around forever, can you? Surely you
> have to recycle them sooner or later or you will run out of disk space.
You couldn't use that as a permanent setting, but
On Fri, Apr 30, 2010 at 2:08 PM, Simon Riggs wrote:
> On Fri, 2010-04-30 at 13:52 -0400, Robert Haas wrote:
>> On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs wrote:
>> > On Fri, 2010-04-30 at 12:22 -0400, Bruce Momjian wrote:
>> >> >
>> >> > (wal_keep_segments can be changed without restarting, rig
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Heikki Linnakangas writes:
> >>> Tom Lane wrote:
> If you aren't archiving then there's no guarantee that you'll still have
> a continuous WAL series starting from the start of the backup.
> >>> I wasn't really thi
Robert Haas writes:
> On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs wrote:
>> Why is that not called "max_wal_segments"? wal_keep_segments sounds like
>> its been through Google translate.
> Because it's not a maximum?
Indeed. It would really be more like min_wal_segments, if we wanted to
name
Heikki Linnakangas wrote:
> Robert Haas wrote:
> > On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs wrote:
> >> On Fri, 2010-04-30 at 12:22 -0400, Bruce Momjian wrote:
> (wal_keep_segments can be changed without restarting, right?)
> >>> Should we allow -1 to mean "keep all segments"?
> >> Why is
Heikki Linnakangas wrote:
> Yeah, min_wal_segments or something would make sense.
Surely it would confuse people to see they have fewer than
min_wal_segments WAL segments.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
Bruce Momjian wrote:
> Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> Tom Lane wrote:
If you aren't archiving then there's no guarantee that you'll still have
a continuous WAL series starting from the start of the backup.
>>> I wasn't really thinking of this use case, but you could se
Robert Haas wrote:
> On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs wrote:
>> On Fri, 2010-04-30 at 12:22 -0400, Bruce Momjian wrote:
(wal_keep_segments can be changed without restarting, right?)
>>> Should we allow -1 to mean "keep all segments"?
>> Why is that not called "max_wal_segments"? w
On Fri, 2010-04-30 at 13:58 -0400, Bruce Momjian wrote:
> Robert Haas wrote:
> > On Fri, Apr 30, 2010 at 1:39 PM, Bruce Momjian wrote:
> > > Robert Haas wrote:
> > >> On Fri, Apr 30, 2010 at 12:22 PM, Bruce Momjian wrote:
> > >> > Tom Lane wrote:
> > >> >> Heikki Linnakangas writes:
> > >> >> >
On Fri, 2010-04-30 at 13:52 -0400, Robert Haas wrote:
> On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs wrote:
> > On Fri, 2010-04-30 at 12:22 -0400, Bruce Momjian wrote:
> >> >
> >> > (wal_keep_segments can be changed without restarting, right?)
> >>
> >> Should we allow -1 to mean "keep all segment
Robert Haas wrote:
> On Fri, Apr 30, 2010 at 1:39 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Fri, Apr 30, 2010 at 12:22 PM, Bruce Momjian wrote:
> >> > Tom Lane wrote:
> >> >> Heikki Linnakangas writes:
> >> >> > Tom Lane wrote:
> >> >> >> If you aren't archiving then there's no gua
On 04/30/2010 01:53 PM, Robert Haas wrote:
Well, one of us is. Why would you want to retain all of your WAL logs
in pg_xlog forever?
...Robert
To create or re-synchronize SR slaves, one could change
wal_keep_segments to -1, run a backup, wait for the slaves to catch up,
and change it back
On Fri, Apr 30, 2010 at 1:39 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Fri, Apr 30, 2010 at 12:22 PM, Bruce Momjian wrote:
>> > Tom Lane wrote:
>> >> Heikki Linnakangas writes:
>> >> > Tom Lane wrote:
>> >> >> If you aren't archiving then there's no guarantee that you'll still
>> >> >
On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs wrote:
> On Fri, 2010-04-30 at 12:22 -0400, Bruce Momjian wrote:
>> >
>> > (wal_keep_segments can be changed without restarting, right?)
>>
>> Should we allow -1 to mean "keep all segments"?
>
> Why is that not called "max_wal_segments"? wal_keep_segmen
Simon Riggs wrote:
> On Fri, 2010-04-30 at 12:22 -0400, Bruce Momjian wrote:
> > >
> > > (wal_keep_segments can be changed without restarting, right?)
> >
> > Should we allow -1 to mean "keep all segments"?
>
> Why is that not called "max_wal_segments"? wal_keep_segments sounds like
> its been t
On Fri, 2010-04-30 at 12:22 -0400, Bruce Momjian wrote:
> >
> > (wal_keep_segments can be changed without restarting, right?)
>
> Should we allow -1 to mean "keep all segments"?
Why is that not called "max_wal_segments"? wal_keep_segments sounds like
its been through Google translate.
--
Simo
Robert Haas wrote:
> On Fri, Apr 30, 2010 at 12:22 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Heikki Linnakangas writes:
> >> > Tom Lane wrote:
> >> >> If you aren't archiving then there's no guarantee that you'll still have
> >> >> a continuous WAL series starting from the start of the ba
On Fri, Apr 30, 2010 at 12:22 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Heikki Linnakangas writes:
>> > Tom Lane wrote:
>> >> If you aren't archiving then there's no guarantee that you'll still have
>> >> a continuous WAL series starting from the start of the backup.
>>
>> > I wasn't really t
Tom Lane wrote:
> Heikki Linnakangas writes:
> > Tom Lane wrote:
> >> If you aren't archiving then there's no guarantee that you'll still have
> >> a continuous WAL series starting from the start of the backup.
>
> > I wasn't really thinking of this use case, but you could set
> > wal_keep_segmen
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Yeah. ISTM the real bottom line here is that we have only a weak grasp
>> on how these features will end up being used; or for that matter what
>> the common error scenarios will be. I think that for the time being
>> we should err on the side of b
On Thu, Apr 29, 2010 at 5:38 AM, Heikki Linnakangas
wrote:
> NOTICE: WAL archiving is not enabled, you must ensure that all required
> WAL segments are streamed or copied through other means to restore the
> backup
I might think about dropping the words "through other means" from this sentence.
Tom Lane wrote:
> Yeah. ISTM the real bottom line here is that we have only a weak grasp
> on how these features will end up being used; or for that matter what
> the common error scenarios will be. I think that for the time being
> we should err on the side of being permissive. We can tighten t
On Wed, 2010-04-28 at 22:17 +0200, Dimitri Fontaine wrote:
> IMO the real fun begins when we talk about multi-slaves support and
> their roles (a failover slave wants the master to wait for it to have
> applied the WAL before to commit, a reporting slave not so much). So
> you'd set the Availabili
Dimitri Fontaine wrote:
IMO the real fun begins when we talk about multi-slaves support and
their roles (a failover slave wants the master to wait for it to have
applied the WAL before to commit, a reporting slave not so much). So
you'd set the Availability level on each slave and wouldn't commit
Aidan Van Dyk wrote:
I remember a presentation at pgcon a while ago, it was probaly Fujii
(from NTT?) about their log streaming, and at that time, they talked
about different "sync" options...
It's all outlined at
http://wiki.postgresql.org/wiki/Streaming_Replication#Synchronization_capability
* Kevin Grittner [100428 15:51]:
> > I don't personally care about streaming replication replaying WAL
> > as it comes, or running queries in recovery...
>
> I'm with you that far, but I wouldn't want the sender to wait for
> remote persistence.
I remember a presentation at pgcon a while ago
"Kevin Grittner" writes:
> Aidan Van Dyk wrote:
>
>> I'm hoping to be able to build a tool that:
>>
>> 1) Connects to PG walsender (a la walreceiver)
>> 2) Streams WAL from pg master
>> 3) Saves WAL into "files" (a la archive)...
>>
>> i.e. I'm looking to keep a more-up-to-date PITR archive t
Aidan Van Dyk wrote:
> I'm hoping to be able to build a tool that:
>
> 1) Connects to PG walsender (a la walreceiver)
> 2) Streams WAL from pg master
> 3) Saves WAL into "files" (a la archive)...
>
> i.e. I'm looking to keep a more-up-to-date PITR archive than
> waiting for traditional WAL fil
Heikki Linnakangas writes:
> Hmm, you could start streaming the WAL before you start the backup, so
> the fact that you've already removed some segments that are needed to
> restore from the backup by the time pg_stop_backup() is called doesn't
> necessarily mean that the backup is useless.
> You
* Heikki Linnakangas [100428 14:49]:
> You'd need a stand-alone tool to do the streaming in that case, and no
> such tool exists yet, but I would be surprised if one doesn't appear on
> pgfoundry sooner or later :-).
And this tool is something I will eventually be interested in working on
or co
Simon Riggs wrote:
> On Wed, 2010-04-28 at 14:21 -0400, Tom Lane wrote:
>> Is there any use in looking
>> at wal_keep_segments as part of this test?
>
> I would hope that pg_stop_backup() will have a conditional ERROR message
> to say
>
> ERROR backup inconsistent and cannot be used for SR
> HINT
On Wed, 2010-04-28 at 14:21 -0400, Tom Lane wrote:
> Is there any use in looking
> at wal_keep_segments as part of this test?
I would hope that pg_stop_backup() will have a conditional ERROR message
to say
ERROR backup inconsistent and cannot be used for SR
HINT increase wal_keep_segments or enab
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Tom Lane wrote:
>>> If you aren't archiving then there's no guarantee that you'll still have
>>> a continuous WAL series starting from the start of the backup.
>
>> I wasn't really thinking of this use case, but you could set
>> wal_keep_segments "h
Heikki Linnakangas wrote:
> Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> Well, it would be nice to allow using pg_start_backup() on the primary
>>> when streaming replication is enabled, even if archiving isn't.
>>> Otherwise the only way to get the base backup for the standby is to shut
>>>
Heikki Linnakangas writes:
> Tom Lane wrote:
>> If you aren't archiving then there's no guarantee that you'll still have
>> a continuous WAL series starting from the start of the backup.
> I wasn't really thinking of this use case, but you could set
> wal_keep_segments "high enough".
Ah. Okay,
On Wed, 2010-04-28 at 11:11 -0700, Josh Berkus wrote:
> > IOW I think that the requirement in pg_start_backup shouldn't be relaxed
> > without some more thought/work.
>
> Yeah, I was talking to Bruce about that this AM, and it seems like a
> feature we *need* to have ... for 9.1.
>
> I'm sufficie
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Well, it would be nice to allow using pg_start_backup() on the primary
>> when streaming replication is enabled, even if archiving isn't.
>> Otherwise the only way to get the base backup for the standby is to shut
>> down primary first, or use filesy
> IOW I think that the requirement in pg_start_backup shouldn't be relaxed
> without some more thought/work.
Yeah, I was talking to Bruce about that this AM, and it seems like a
feature we *need* to have ... for 9.1.
I'm sufficiently concerned about the amount of flux HS/SR is in right
now that
Heikki Linnakangas writes:
> Well, it would be nice to allow using pg_start_backup() on the primary
> when streaming replication is enabled, even if archiving isn't.
> Otherwise the only way to get the base backup for the standby is to shut
> down primary first, or use filesystem snapshot etc.
I
Robert Haas wrote:
> but
> what do you mean by "except with filesystem-level snapshot
> capabilities"?
If you have a filesystem that supports atomic snapshots, you can take a
snapshot of the filesystem the data directory resides on, and then copy
the data directory from the snapshot at your leisur
On Wed, 2010-04-28 at 12:44 -0400, Robert Haas wrote:
> On Wed, Apr 28, 2010 at 11:25 AM, Heikki Linnakangas
> wrote:
> > Robert Haas wrote:
> >> At least as I understand it, even when not using
> >> archive_mode, streaming replication, or hot standby, it's still
> >> perfectly legal to use pg_sta
On Wed, Apr 28, 2010 at 11:25 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> At least as I understand it, even when not using
>> archive_mode, streaming replication, or hot standby, it's still
>> perfectly legal to use pg_start_backup() to take a hot backup.
>
> Nope. The correct procedure
On Wed, 2010-04-28 at 11:10 -0400, Robert Haas wrote:
> >
> > IIRC it was you that suggested changing the names of things if the
> > behaviour changes.
>
> Absolutely, but I'm arguing that we shouldn't change the behavior in
> the first place. At least as I understand it...
I feel like you're ju
Heikki Linnakangas writes:
> Which is unfortunate, really. I wish we had a mode where the server
> simply refrained from removing/recycling WAL segments while the backup
> is running. You could then just:
> 1. pg_start_backup()
> 2. tar the data directory, except for pg_xlog
> 3. tar pg_xlog
> 4.
Robert Haas wrote:
> At least as I understand it, even when not using
> archive_mode, streaming replication, or hot standby, it's still
> perfectly legal to use pg_start_backup() to take a hot backup.
Nope. The correct procedure to take a hot backup is described in
http://www.postgresql.org/docs/8
On Wed, Apr 28, 2010 at 7:22 AM, Simon Riggs wrote:
> On Wed, 2010-04-28 at 06:56 -0400, Robert Haas wrote:
>> On Wed, Apr 28, 2010 at 6:52 AM, Simon Riggs wrote:
>> > On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote:
>> >> On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
>> >> wrote:
>>
On Wed, Apr 28, 2010 at 8:28 PM, Heikki Linnakangas
wrote:
> Or maybe we should check in pg_start_backup() that either archive_mode
> or streaming replication (max_wal_senders > 0) is enabled.
I agree that pg_start_backup checks not only wal_level but also that.
Regards,
--
Fujii Masao
NIPPON
Robert Haas wrote:
> On Wed, Apr 28, 2010 at 6:52 AM, Simon Riggs wrote:
>> On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote:
>>> On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
>>> wrote:
This doesn't contain any changes to pg_start_backup() yet, that's a
separate issue and sti
On Wed, 2010-04-28 at 06:56 -0400, Robert Haas wrote:
> On Wed, Apr 28, 2010 at 6:52 AM, Simon Riggs wrote:
> > On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote:
> >> On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
> >> wrote:
> >> > This doesn't contain any changes to pg_start_backup() y
On Wed, Apr 28, 2010 at 6:52 AM, Simon Riggs wrote:
> On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote:
>> On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
>> wrote:
>> > This doesn't contain any changes to pg_start_backup() yet, that's a
>> > separate issue and still under discussion.
>>
On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote:
> On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
> wrote:
> > This doesn't contain any changes to pg_start_backup() yet, that's a
> > separate issue and still under discussion.
>
> I'm thinking of changing pg_start_backup and pg_stop_back
66 matches
Mail list logo
