Hi everyone,
In order to clarify things, how about we do a formal vote with specific
details like this:
***
Are you for...
- pg_xlog directory changeable at all, not using symlinks?
Yes/No
- a PGXLOG environment variable to do this?
Yes/No
- a -X command line option to do this?
Curt Sampson wrote:
On Wed, 25 Sep 2002, Jan Wieck wrote:
With the number of screws our product has, there are so many
possible combinations that don't work, why worry about one more
or less?
That's just silly, so I won't even bother replying.
Curt,
it might sound silly on first
On Thu, 26 Sep 2002, Jan Wieck wrote:
But still, why set up a situation where your database might not
start? Why not set it up so that if you get just *one* environment
or command-line variable right, you can't set another inconsistently
and screw up your start anyway? Why store
On Wed, 25 Sep 2002, Curt Sampson wrote:
On Tue, 24 Sep 2002, Jan Wieck wrote:
And AFAICS it is scary only because screwing that up will simply corrupt
your database. Thus, a simple random number (okay, and a timestamp of
initdb) in two files, one in $PGDATA and one in $PGXLOG would be
I don't see the gain of having a file called pg_xlog vs. using GUC.
---
scott.marlowe wrote:
On Wed, 25 Sep 2002, Curt Sampson wrote:
On Tue, 24 Sep 2002, Jan Wieck wrote:
And AFAICS it is scary only because
I do.
The problem is that if you change the location of pg_xlog and do one thing
wrong, poof, your database is now corrupt. Like Tom said earlier, imagine
a command like switch called please-dont-scram-my-database and if you
ever forgot it then your data is gone.
Is it better to move such a
Curt Sampson wrote:
On Tue, 24 Sep 2002, Jan Wieck wrote:
And AFAICS it is scary only because screwing that up will simply corrupt
your database. Thus, a simple random number (okay, and a timestamp of
initdb) in two files, one in $PGDATA and one in $PGXLOG would be a
totally
Bruce Momjian [EMAIL PROTECTED] writes:
I don't see the gain of having a file called pg_xlog vs. using GUC.
Well, the point is to have a safety interlock --- but I like Jan's
idea of using matching identification files in both directories.
With that, a GUC variable seems just fine.
On Wed, 25 Sep 2002, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I don't see the gain of having a file called pg_xlog vs. using GUC.
Well, the point is to have a safety interlock --- but I like Jan's
idea of using matching identification files in both directories.
With that,
scott.marlowe wrote:
Having a FILE called pg_xlog isn't the fix here, it's the result of the
fix, which is to take all the steps of moving the pg_xlog directory and
put them into one script file the user doesn't need to understand to do it
right. I.e. idiot proof the system as much as
On Wed, 25 Sep 2002, Jan Wieck wrote:
With the number of screws our product has, there are so many
possible combinations that don't work, why worry about one more
or less?
That's just silly, so I won't even bother replying.
Seriously, if you move around files, make symlinks or adjust
On Wed, 25 Sep 2002, Jan Wieck wrote:
scott.marlowe wrote:
Having a FILE called pg_xlog isn't the fix here, it's the result of the
fix, which is to take all the steps of moving the pg_xlog directory and
put them into one script file the user doesn't need to understand to do it
right.
scott.marlowe wrote:
On Wed, 25 Sep 2002, Jan Wieck wrote:
So, should we take out seatbelts from cars, safeties from guns, and have
everyone run about with sharp sticks too? :-) I know that the second we
make something more idiot proof, someone will make a better idiot, but
that doesn't
scott.marlowe wrote:
[...]
But, I have a few more questions about the signature file solution. Is
the signature file going to be updated by date or something everytime the
database is started up and shut down? If not, then it's quite possible
that someone could copy the pg_xlog dir
Bruce Momjian wrote:
scott.marlowe wrote:
On Wed, 25 Sep 2002, Jan Wieck wrote:
So, should we take out seatbelts from cars, safeties from guns, and have
everyone run about with sharp sticks too? :-) I know that the second we
make something more idiot proof, someone will make a better
Bruce Momjian [EMAIL PROTECTED] writes:
Can we wait for someone to be injured in a car accident before putting
in heavy seat belts?
Not the analogy you wanted to make ... if you knew there was a serious
risk, that's called negligence in most American courts. Ask Ford about
the Pinto ...
On 19 Sep 2002, Greg Copeland wrote:
I think Marc made a pretty good case about the use of command line
arguments but I think I have to vote with Tom. Many of the command line
arguments you seem to be using do sorta make sense to have for easy
reference or to help validate your runtime
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
You don't :vote: on stuff like this ...
Why not, exactly?
I wasn't aware that any of core had a non-vetoable right to apply
any patch we liked regardless of the number and strength of the
objections. AFAIK, we resolve
Jan Wieck wrote:
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
You don't :vote: on stuff like this ...
Why not, exactly?
I wasn't aware that any of core had a non-vetoable right to apply
any patch we liked regardless of the number and strength of the
Jan Wieck [EMAIL PROTECTED] writes:
And AFAICS it is scary only because screwing that up will simply corrupt
your database. Thus, a simple random number (okay, and a timestamp of
initdb) in two files, one in $PGDATA and one in $PGXLOG would be a
totally sufficient safety mechanism to prevent
On Tue, 24 Sep 2002, Jan Wieck wrote:
And AFAICS it is scary only because screwing that up will simply corrupt
your database. Thus, a simple random number (okay, and a timestamp of
initdb) in two files, one in $PGDATA and one in $PGXLOG would be a
totally sufficient safety mechanism to
On Sun, 22 Sep 2002, Tom Lane wrote:
It was pretty clear that Thomas' original patch lost the vote, or
would have lost if we'd bothered to hold a formal vote.
Hasn't there just been a formal vote on this?
I don't
see anyone arguing against the notion of making XLOG location more
easily
Nigel J. Andrews wrote:
snip
And it's obvious it was centred on the use of an environment variable from the
subject line, it's still got PGXLOG in capitals in it.
Actually, to be really precise, my original email asked for an
environment variable. But only because I'd thought about it from
On Sun, 22 Sep 2002, Marc G. Fournier wrote:
Thomas implemented an option that he felt was useful, and that doesn't
break anything inside of the code ... he provided 2 methods of being able
to move the xlog's to another location (through command line and
environment variable, both of which
On Fri, 20 Sep 2002, Bruce Momjian wrote:
In fact, I tried to open a dialog with you on this issue several times,
but when I got no reply, I had to remove PGXLOG. If we had continued
discussion, we might have come up with the GUC compromise.
Ya know, I'm sitting back and reading this, and
Marc G. Fournier wrote:
On Fri, 20 Sep 2002, Bruce Momjian wrote:
In fact, I tried to open a dialog with you on this issue several times,
but when I got no reply, I had to remove PGXLOG. If we had continued
discussion, we might have come up with the GUC compromise.
Ya know, I'm
On Sun, 22 Sep 2002, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Fri, 20 Sep 2002, Bruce Momjian wrote:
In fact, I tried to open a dialog with you on this issue several times,
but when I got no reply, I had to remove PGXLOG. If we had continued
discussion, we might have come
Marc G. Fournier [EMAIL PROTECTED] writes:
Ya know, I'm sitting back and reading this, and other threads, and
assimilating what is being bantered about, and start to think that
its time to cut back on the gatekeepers ...
On the contrary, the quality of code accepted into a DBMS is really
Marc G. Fournier wrote:
However, if you don't accept voting as a valid way to determine if a
patch is acceptible, what method do you suggest? I don't think we want
to go down the road of saying that you can't vote no on a feature
addition.
We just rejected a patch today on LIMIT with
Marc G. Fournier [EMAIL PROTECTED] writes:
You don't :vote: on stuff like this ...
Why not, exactly?
I wasn't aware that any of core had a non-vetoable right to apply
any patch we liked regardless of the number and strength of the
objections. AFAIK, we resolve differences of opinion by
On Fri, 20 Sep 2002, Thomas Lockhart wrote:
Well, what I was hoping for, but no longer expect, is that features
(store xlog in another area) can be implemented and applied without
rejection by the new gatekeepers.
It can be, and very simply. So long as you do it in the way which
is not
On Thu, 19 Sep 2002, Thomas Lockhart wrote:
Actually, a core member did implement this just a few weeks ago. The
same crew arguing this time rejected the changes and removed them from
the 7.3 feature set.
The change to make a PG_XLOG environment variable was rejected. Is that
really the
Thomas Lockhart wrote:
...
Why you object to that, and insist it must be an environment variable
instead (if that is indeed what you're doing), I'm not sure
Well, what I was hoping for, but no longer expect, is that features
(store xlog in another area) can be implemented and applied
On Wed, 2002-09-18 at 22:24, Marc G. Fournier wrote:
On Wed, 18 Sep 2002, Bruce Momjian wrote:
Sorry, I don't see the logic here. Using postgresql.conf, you set it
once and it remains set until you change it again. With -X, you have to
use it every time. I think that's where the votes
I think Marc made a pretty good case about the use of command line
arguments but I think I have to vote with Tom. Many of the command line
arguments you seem to be using do sorta make sense to have for easy
reference or to help validate your runtime environment for each
instance. The other side
On Thu, 19 Sep 2002, Robert Treat wrote:
I don't know if I agree with that. Most servers (apache for instance) have
configuration variables on where files are going to live, not command line
options.
Not where it involves *critical* files:
OPTIONS
-R libexecdir
On Thu, 19 September 2002, Marc G. Fournier wrote:
On Thu, 19 Sep 2002, Robert Treat wrote:
gt; Well, as with most (all?) GUC variables, wouldn't you have the option of
gt; doing postmaster -o quot;pgxlog=/dev/nullquot; and have the same
functionality
gt; as -X ?
True, but then that
It seems all of this discussion misses the point. Either it has a large
amount of impact and the idea gets rejected because of implementation
issues, or it has little impact but it's nothing the core group wants to
implement. If the problem is finding someone to implement it, it sounds
like
Robert Treat wrote:
It seems all of this discussion misses the point. Either it has a large
amount of impact and the idea gets rejected because of implementation
issues, or it has little impact but it's nothing the core group wants to
implement. If the problem is finding someone to implement
Marc G. Fournier writes:
My point is, the functionality is there, and should be documented properly
... encourage ppl to use the GUC setting in postmaster.conf, but just
because you can't grasp that some of us *like* to use command line args,
don't remove such functionality ...
Top secret
On Tue, 17 Sep 2002, Bruce Momjian wrote:
Dave Page wrote:
Which in this case is what puzzles me. We are only talking about a
simple GUC variable after all - I don't know for sure, but I'm guessing
it's not a huge effort to add one?
Can we get agreement on that? A GUC for pg_xlog
Marc G. Fournier wrote:
On Tue, 17 Sep 2002, Bruce Momjian wrote:
Dave Page wrote:
Which in this case is what puzzles me. We are only talking about a
simple GUC variable after all - I don't know for sure, but I'm guessing
it's not a huge effort to add one?
Can we get agreement
On Wed, 18 Sep 2002, Bruce Momjian wrote:
Sorry, I don't see the logic here. Using postgresql.conf, you set it
once and it remains set until you change it again. With -X, you have to
use it every time. I think that's where the votes came from.
Ah, so you are saying that you type out your
Marc G. Fournier wrote:
On Wed, 18 Sep 2002, Bruce Momjian wrote:
Sorry, I don't see the logic here. Using postgresql.conf, you set it
once and it remains set until you change it again. With -X, you have to
use it every time. I think that's where the votes came from.
Ah, so you are
Marc G. Fournier [EMAIL PROTECTED] writes:
On Wed, 18 Sep 2002, Bruce Momjian wrote:
Sorry, I don't see the logic here. Using postgresql.conf, you set it
once and it remains set until you change it again. With -X, you have to
use it every time. I think that's where the votes came from.
On Wed, 18 Sep 2002, Bruce Momjian wrote:
Yea, but you aren't going to be needing to know the xlog directory that
way, will you?
Why not? Who are you to tell me how my scripts work, or how they get
their information? I have a script that runs to tell me how much disk
space each instance is
Marc G. Fournier wrote:
On Wed, 18 Sep 2002, Bruce Momjian wrote:
Yea, but you aren't going to be needing to know the xlog directory that
way, will you?
Why not? Who are you to tell me how my scripts work, or how they get
their information? I have a script that runs to tell me how
On Wed, 18 Sep 2002, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Wed, 18 Sep 2002, Bruce Momjian wrote:
Sorry, I don't see the logic here. Using postgresql.conf, you set it
once and it remains set until you change it again. With -X, you have to
use it every time. I
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: 17 September 2002 06:36
To: Christopher Kings-Lynne
Cc: Robert Treat; Justin Clift; Peter Eisentraut; Tom Lane;
Curt Sampson; PostgreSQL Hackers Mailing List
Subject: Re: [HACKERS] PGXLOG variable
I use PostgreSQL on Linux for production and XP for development, and am
likely to continue that way. I've been beta testing the native Win32
port of PostgreSQL as Justin has and the latest version is fantastic -
it runs as a service, osdb shows impressive results compared to Cygwin
On 17 Sep 2002 at 16:11, Christopher Kings-Lynne wrote:
What I can't understand is the attitude of some people here. Yes,
Microsoft are evil, but the bottom line is, millions of people use
Windows. Just look at the number of downloads for pgAdmin (shown at
-Original Message-
From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]]
Sent: 17 September 2002 09:05
To: Dave Page; Bruce Momjian
Cc: Robert Treat; Justin Clift; Peter Eisentraut; Tom Lane;
Curt Sampson; PostgreSQL Hackers Mailing List
Subject: RE: [HACKERS] PGXLOG
-Original Message-
From: Shridhar Daithankar
[mailto:[EMAIL PROTECTED]]
Sent: 17 September 2002 09:30
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] PGXLOG variable worthwhile?
On 17 Sep 2002 at 16:11, Christopher Kings-Lynne wrote:
But I disagree
Let's leave it. The main point to focus postgres on unix is not
only because
unix is proven/known as robust and scalable, but unix is much
more standard to
support across multiple OS. The amount with which windows differs
from unices
on API level, any serious efforts to make postgresql
-Original Message-
From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]]
Sent: 17 September 2002 09:49
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] PGXLOG variable worthwhile?
Users HAVE provided their feedback - they want Postgres
Dave Page wrote:
Which in this case is what puzzles me. We are only talking about a
simple GUC variable after all - I don't know for sure, but I'm guessing
it's not a huge effort to add one?
Can we get agreement on that? A GUC for pg_xlog location? Much cleaner
than -X, doesn't have the
On Tue, 17 Sep 2002, Bruce Momjian wrote:
Dave Page wrote:
Which in this case is what puzzles me. We are only talking about a
simple GUC variable after all - I don't know for sure, but I'm guessing
it's not a huge effort to add one?
Can we get agreement on that? A GUC for pg_xlog
Nigel J. Andrews wrote:
snip
However, how is that going to work if tablespaces are introduced in 7.4. Surely
the same mechanism for tablespaces would be used for pg_xlog. As the tablespace
mechanism hasn't been determined yet, as far as I know, wouldn't it be best to
see what happens there
Nigel J. Andrews wrote:
On Tue, 17 Sep 2002, Bruce Momjian wrote:
Dave Page wrote:
Which in this case is what puzzles me. We are only talking about a
simple GUC variable after all - I don't know for sure, but I'm guessing
it's not a huge effort to add one?
Can we get agreement
I forget, is it possible to make a GUC that cannot be changed during
runtime?
If so, then I vote yes, otherwise, there is a problem if someone tries.
On Tue, 2002-09-17 at 17:07, Bruce Momjian wrote:
Dave Page wrote:
Which in this case is what puzzles me. We are only talking about a
Rod Taylor wrote:
I forget, is it possible to make a GUC that cannot be changed during
runtime?
Yes, you can set it to it only can be changed by the super-user and only
takes effect on restart.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
Bruce Momjian wrote:
Dave Page wrote:
Which in this case is what puzzles me. We are only talking about a
simple GUC variable after all - I don't know for sure, but I'm guessing
it's not a huge effort to add one?
Can we get agreement on that? A GUC for pg_xlog location? Much cleaner
Nigel J. Andrews wrote:
However, how is that going to work if tablespaces are introduced in 7.4. Surely
the same mechanism for tablespaces would be used for pg_xlog. As the tablespace
mechanism hasn't been determined yet, as far as I know, wouldn't it be best to
see what happens there before
Jan Wieck wrote:
Nigel J. Andrews wrote:
However, how is that going to work if tablespaces are introduced in 7.4. Surely
the same mechanism for tablespaces would be used for pg_xlog. As the tablespace
mechanism hasn't been determined yet, as far as I know, wouldn't it be best to
see what
Robert Treat wrote:
It seems all of this discussion misses the point. Either it has a large
amount of impact and the idea gets rejected because of implementation
issues, or it has little impact but it's nothing the core group wants to
implement. If the problem is finding someone to implement
It seems all of this discussion misses the point. Either it has a large
amount of impact and the idea gets rejected because of implementation
issues, or it has little impact but it's nothing the core group wants to
implement. If the problem is finding someone to implement it, it sounds
Christopher Kings-Lynne wrote:
It seems all of this discussion misses the point. Either it has a large
amount of impact and the idea gets rejected because of implementation
issues, or it has little impact but it's nothing the core group wants to
implement. If the problem is finding
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: 12 September 2002 06:27
To: Justin Clift
Cc: PostgreSQL Hackers Mailing List
Subject: Re: [HACKERS] PGXLOG variable worthwhile?
Also, I have heard symlinks are available in native Windows
Mike Mascari wrote:
snip
In Windows 2000 and Windows XP with an NTFS filesystem,
Microsoft has added Reparse Points, which allow for the
implementation of symbolic links for directories. Microsoft
calls them Junctions. I *believe* the function used for
creating reparse points is
On Thu, 12 Sep 2002, Justin Clift wrote:
Mike Mascari wrote:
snip
In Windows 2000 and Windows XP with an NTFS filesystem,
Microsoft has added Reparse Points, which allow for the
implementation of symbolic links for directories. Microsoft
calls them Junctions. I *believe* the function
On Thu, 12 Sep 2002, Justin Clift wrote:
Am just wondering if we've ever considered adding a PGXLOG environment
variable that would point to the pg_xlog directory?
IMHO, a much better way to support this is to put this information into
the config file. That way it can't easily change when you
scott.marlowe wrote:
On Fri, 13 Sep 2002, Justin Clift wrote:
Would it be correct to say that the 'ln' command in the MS Resource Kit
creates this kind of shortcut too, as the Reparse Points feature doesn't
seem to be possible under NT4?
I wouldn't assume that. It's been years since I
I wrote:
scott.marlowe wrote:
I wouldn't assume that. It's been years since I tested it, but back
then, the command line and all program I used could see the link
created by ln that came with the resource kit. They were distinctly
different from the shortcut type of links, in that
Hi everyone,
Am just wondering if we've ever considered adding a PGXLOG environment
variable that would point to the pg_xlog directory?
In a Unix environment it's not real necessary as filesystem links can be
created, but in other environments (i.e. the Native windows port) it's
looking like it
We dealt this this (painfully) during 7.3 development. Some wanted a -X
flag to initdb/postgres/postmaster that would identify the pg_xlog
directory while others wanted the flag only on initdb and have initdb
create a symlink.
Finally, we decided to do nothing. and continue to recommend
75 matches
Mail list logo
