"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> I would opt to make enabling/disabling archive_command require a postmaster
> restart. That way there would be no capability to take advantage of the
> incentive to turn it on/off.
We're generally not in the habit of making GUC parameters more rigi
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Now, if you say people will rarely turn archiving on/off, then one
> > > parameter seems to make more sense.
> >
> > I really can't envision a situation where people would do that. If you
> > need PITR at all then you need it 2
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Now, if you say people will rarely turn archiving on/off, then one
> > parameter seems to make more sense.
>
> I really can't envision a situation where people would do that. If you
> need PITR at all then you need it 24x7.
OK, then
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Now, if you say people will rarely turn archiving on/off, then one
> parameter seems to make more sense.
I really can't envision a situation where people would do that. If you
need PITR at all then you need it 24x7.
regards, tom
Bruce Momjian wrote:
>
> I do think we need a boolean for start/stop of archiving, rather than
> setting it to '' to turn it off. Tom, I think the group agreed to this
> on clarity grounds. I would like the server to throw an error if you
> try to turn on archiving and the command is set to ''.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I do think we need a boolean for start/stop of archiving, rather than
> > setting it to '' to turn it off. Tom, I think the group agreed to this
> > on clarity grounds.
>
> I didn't see any consensus there, nor do I see a point to it
I do think we need a boolean for start/stop of archiving, rather than
setting it to '' to turn it off. Tom, I think the group agreed to this
on clarity grounds. I would like the server to throw an error if you
try to turn on archiving and the command is set to ''.
--
On Wed, 2004-07-21 at 15:53, Tom Lane wrote:
> Klaus Naumann <[EMAIL PROTECTED]> writes:
> > Simon doesn't mean the recovery part. Instead he means the "normal"
> > startup of the server. It has to be absolutely clear (in the logfile!) if
> > the server was started in archive mode or not. Otherwise
Klaus Naumann <[EMAIL PROTECTED]> writes:
> Simon doesn't mean the recovery part. Instead he means the "normal"
> startup of the server. It has to be absolutely clear (in the logfile!) if
> the server was started in archive mode or not. Otherwise you always have
> to guess.
Why would you guess? "
On Wed, 21 Jul 2004, Tom Lane wrote:
Hi Tom,
Simon doesn't mean the recovery part. Instead he means the "normal"
startup of the server. It has to be absolutely clear (in the logfile!) if
the server was started in archive mode or not. Otherwise you always have
to guess.
On server startup there sho
Simon Riggs <[EMAIL PROTECTED]> writes:
> A more important omission is the deletion of a message to indicate that
> the server is acting in archive_modeso there's no visual clue in the
> log to warn an admin that its been turned off now or incorrectly
> specified (by somebody else, of course).
I'm in favour of how it is now, so long as the comment is clear. It's
the Unix Way :)
Chris
I'd vote for it as a clarity factor too.
Klaus Naumann wrote:
On Tue, 20 Jul 2004 [EMAIL PROTECTED] wrote:
FATAL: unrecognized configuration parameter "archive_mode"
Have I missed something since it h
I'd vote for it as a clarity factor too.
Klaus Naumann wrote:
On Tue, 20 Jul 2004 [EMAIL PROTECTED] wrote:
FATAL: unrecognized configuration parameter "archive_mode"
Have I missed something since it has been committed?
Yes, Tom has removed this option in favorite of just setting
archive_co
On Tue, 2004-07-20 at 17:29, Klaus Naumann wrote:
> On Tue, 20 Jul 2004 [EMAIL PROTECTED] wrote:
>
> > FATAL: unrecognized configuration parameter "archive_mode"
> >
> > Have I missed something since it has been committed?
>
> Yes, Tom has removed this option in favorite of just setting
> archiv
On Tue, 20 Jul 2004 [EMAIL PROTECTED] wrote:
> FATAL: unrecognized configuration parameter "archive_mode"
>
> Have I missed something since it has been committed?
Yes, Tom has removed this option in favorite of just setting
archive_command to a value which then enables the PITR code also.
But a
On 18 Jul, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> Latest version, pitr_v5_2.patch...
>
> Reviewed and committed with some adjustments.
I pull from CVS and and got the following message when I tried starting
the database with the archive_mode parameter:
FATAL: unrecognized
Okay, we agree on that part at least; I'll take care of it. If anyone
wants to argue for further copying during initdb, that can be added
later.
I reckon it should be copied into $PGDATA :) Otherwise, when I'm in a
panic at recovery time, I'd have to figure out where the heck my package
has ins
On Mon, 2004-07-19 at 17:56, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I had second thoughts about that and didn't do it in the committed
> >> patch, though it's certainly still open for debate.
>
> > How are we handling a crash during recovery?
>
> Retr
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > we need to check to see which one has a WAL eof-of-segment marker (we
> > have on of those, right?).
>
> No, we don't.
>
> > I think I see a solution. We are going to create a file during backup so
> > we know the wal offsets and xid
Bruce Momjian <[EMAIL PROTECTED]> writes:
> we need to check to see which one has a WAL eof-of-segment marker (we
> have on of those, right?).
No, we don't.
> I think I see a solution. We are going to create a file during backup so
> we know the wal offsets and xids. If we see that file, we know
On Mon, 2004-07-19 at 05:54, Tom Lane wrote:
> code in Simon's original patch that would start bleating
Code that bleats? LOL :) (is that a new log level?)
Some of it was perhaps a little woolly
You've made my day, Simon Riggs (still laughing)
---(end of broadcast)
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> It should certainly go to /share as a .sample file. I was thinking that
> >> initdb should perhaps copy it into $PGDATA (still as .sample, not as
> >> .conf!) so it'd be right there when you need it.
>
> > I thin
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It should certainly go to /share as a .sample file. I was thinking that
>> initdb should perhaps copy it into $PGDATA (still as .sample, not as
>> .conf!) so it'd be right there when you need it.
> I think /share is best.
Okay, we ag
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> * Documentation is, um, lacking. (One point in particular is that I
> >> inserted the recovery.conf.sample file into CVS, but did not fill in
> >> the patch's lack of attempt to install it anywhere.)
>
> > I figu
On Mon, 2004-07-19 at 04:03, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Latest version, pitr_v5_2.patch...
>
> Reviewed and committed with some adjustments.
>
Wow! Thanks very much - you work fast.
I'll be re-testing later today.
> I see the following significant loose ends
On Mon, 2004-07-19 at 04:13, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > When archiver starts the FIRST thing it does is run a test to confirm
> > that the command string works, so setting archive_command to '' would
> > simply generate an error.
>
> No, it would do no such thing
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What is the process of logging to tape? Ideally we could just do 'dd'
> to the tape drive in append mode; however we need a way of signalling
> that we want to change tapes.
The reason we use a user-specifiable shell command for archiving is
so that we
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> * Documentation is, um, lacking. (One point in particular is that I
>> inserted the recovery.conf.sample file into CVS, but did not fill in
>> the patch's lack of attempt to install it anywhere.)
> I figure it should go in share like
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Latest version, pitr_v5_2.patch...
>
> Reviewed and committed with some adjustments.
>
> I see the following significant loose ends:
>
> * Documentation is, um, lacking. (One point in particular is that I
> inserted the recovery.conf
What is the process of logging to tape? Ideally we could just do 'dd'
to the tape drive in append mode; however we need a way of signalling
that we want to change tapes.
The only method I can think of is to have PITR dump the files into a
holding directory, and have a daemon that scans the dire
Simon Riggs <[EMAIL PROTECTED]> writes:
> When archiver starts the FIRST thing it does is run a test to confirm
> that the command string works, so setting archive_command to '' would
> simply generate an error.
No, it would do no such thing; the test cannot really tell anything more
than whether
Simon Riggs <[EMAIL PROTECTED]> writes:
> Latest version, pitr_v5_2.patch...
Reviewed and committed with some adjustments.
I see the following significant loose ends:
* Documentation is, um, lacking. (One point in particular is that I
inserted the recovery.conf.sample file into CVS, but did not
On Sun, 2004-07-18 at 06:04, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > So you want to merge them all into a single command string. That does
> > seem less error-prone. I see a few variables that turn off
> > when set to '' like unix_socket_*. How would this command string w
Bruce Momjian <[EMAIL PROTECTED]> writes:
> So you want to merge them all into a single command string. That does
> seem less error-prone. I see a few variables that turn off
> when set to '' like unix_socket_*. How would this command string work?
> How do you specify the WAL file name to trans
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> What is the point of having both archive_program and archive_dest as
> >> GUC variables?
>
> > I assume archive_dest is used for both archive and recovery of archives.
>
> You assume wrong; it's not used there.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What is the point of having both archive_program and archive_dest as
>> GUC variables?
> I assume archive_dest is used for both archive and recovery of archives.
You assume wrong; it's not used there. There isn't any real good
reason
Tom Lane wrote:
> [ ... some desultory reading of PITR patch ... ]
>
> What is the point of having both archive_program and archive_dest as
> GUC variables? Wouldn't it be simpler to fold them into one parameter,
> viz
>
> archive_command = 'cp %s /archivedir'
>
> For that matter, do we n
[ ... some desultory reading of PITR patch ... ]
What is the point of having both archive_program and archive_dest as
GUC variables? Wouldn't it be simpler to fold them into one parameter,
viz
archive_command = 'cp %s /archivedir'
For that matter, do we need a separate archive_mode bool
38 matches
Mail list logo
