Robert Haas wrote:
On Sat, May 8, 2010 at 10:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us 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
On Sat, 2010-05-08 at 23:55 -0400, Robert Haas wrote:
On Sat, May 8, 2010 at 10:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us 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
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_keep_segments sounds like
Bruce Momjian br...@momjian.us 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.
On Sat, May 8, 2010 at 10:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us 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
Simon Riggs si...@2ndquadrant.com 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
On Mon, May 3, 2010 at 2:54 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Simon Riggs si...@2ndquadrant.com 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
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 Fri, 2010-04-30 at 13:41 -0500, Kevin Grittner wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On Fri, Apr 30, 2010 at 12:22 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Robert Haas wrote:
On Fri, Apr 30, 2010 at 12:22 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
If you aren't archiving then there's no guarantee that you'll still have
a continuous WAL series
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.
--
Simon Riggs
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 through Google
On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs si...@2ndquadrant.com 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?
On Fri, Apr 30, 2010 at 1:39 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Fri, Apr 30, 2010 at 12:22 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
If you aren't archiving then
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
Robert Haas wrote:
On Fri, Apr 30, 2010 at 1:39 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Fri, Apr 30, 2010 at 12:22 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
If
On Fri, 2010-04-30 at 13:52 -0400, Robert Haas wrote:
On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs si...@2ndquadrant.com 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
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 br...@momjian.us wrote:
Robert Haas wrote:
On Fri, Apr 30, 2010 at 12:22 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Heikki Linnakangas
Robert Haas wrote:
On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs si...@2ndquadrant.com 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
Bruce Momjian wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas wrote:
Robert Haas wrote:
On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs si...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs si...@2ndquadrant.com 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
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On Fri, Apr 30, 2010 at 2:08 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2010-04-30 at 13:52 -0400, Robert Haas wrote:
On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2010-04-30 at 12:22 -0400, Bruce Momjian wrote:
(wal_keep_segments can be
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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 Herrera
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,
and
Alvaro Herrera alvhe...@commandprompt.com 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
On Fri, 2010-04-30 at 14:42 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs si...@2ndquadrant.com wrote:
Why is that not called max_wal_segments? wal_keep_segments sounds like
its been through Google translate.
Because it's
Kevin Grittner wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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 Availability
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
On Thu, Apr 29, 2010 at 5:38 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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_backup so that
they just check that
On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote:
On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Wed, Apr 28, 2010 at 6:52 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote:
On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
This doesn't contain any changes to pg_start_backup() yet, that's a
On Wed, 2010-04-28 at 06:56 -0400, Robert Haas wrote:
On Wed, Apr 28, 2010 at 6:52 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote:
On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
This
Robert Haas wrote:
On Wed, Apr 28, 2010 at 6:52 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote:
On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
This doesn't contain any changes to
On Wed, Apr 28, 2010 at 8:28 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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.
On Wed, Apr 28, 2010 at 7:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-04-28 at 06:56 -0400, Robert Haas wrote:
On Wed, Apr 28, 2010 at 6:52 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote:
On Wed, Apr 28, 2010 at 4:43 PM,
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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 just
On Wed, Apr 28, 2010 at 11:25 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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.
On Wed, 2010-04-28 at 12:44 -0400, Robert Haas wrote:
On Wed, Apr 28, 2010 at 11:25 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
At least as I understand it, even when not using
archive_mode, streaming replication, or hot standby, it's still
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 leisure,
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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 sufficiently
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
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 increase
* Heikki Linnakangas heikki.linnakan...@enterprisedb.com [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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Aidan Van Dyk ai...@highrise.ca 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Aidan Van Dyk ai...@highrise.ca 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
* Kevin Grittner kevin.gritt...@wicourts.gov [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
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
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
67 matches
Mail list logo
