On 26/09/17 20:44, Mark Kirkwood wrote:
$ pg_basebackup -D .
WARNING: could not read symbolic link "pg_tblspc/space1": Invalid
argument
pg_basebackup: directory "/data0/pgdata/11/pg_tblspc/space1" exists
but is not empty
pg_basebackup: removing contents of data directory "."
Err -
On 29/04/15 09:35, Bruce Momjian wrote:
On Fri, Apr 24, 2015 at 01:05:03PM -0400, Bruce Momjian wrote:
This way, both pg_dump and pg_upgrade will issue warnings, though, of
course, those warnings can be ignored. I am hopeful these two warnings
will be sufficient and we will not need make
On Fri, Apr 24, 2015 at 01:05:03PM -0400, Bruce Momjian wrote:
This way, both pg_dump and pg_upgrade will issue warnings, though, of
course, those warnings can be ignored. I am hopeful these two warnings
will be sufficient and we will not need make these errors, with the
possible
On Thu, Apr 23, 2015 at 4:30 PM, Andres Freund and...@anarazel.de wrote:
On 2015-04-23 16:26:09 -0400, Robert Haas wrote:
But pg_upgrade automates all that, so you can't use pg_upgrade in that
case. If we add a GUC as I suggested, you can still use pg_upgrade.
But we also have to live with
On Wed, Apr 22, 2015 at 10:41:02PM -0400, Bruce Momjian wrote:
josh=# create tablespace tbl2 location '/home/josh/pg94/data/pg_xlog/';
CREATE TABLESPACE
It really seems like we ought to block *THAT*. Of course, if we block
tablespace creation in PGDATA generally, then that's covered.
On Thu, Apr 23, 2015 at 09:13:52AM -0400, Robert Haas wrote:
On Wed, Apr 22, 2015 at 10:41 PM, Bruce Momjian br...@momjian.us wrote:
What is a real problem is that we don't block creating tablespaces
anywhere at all, including in obviously problematic places like the
transaction log
On Thu, Apr 23, 2015 at 05:05:14PM +0200, Andres Freund wrote:
On 2015-04-23 11:00:43 -0400, Bruce Momjian wrote:
On Thu, Apr 23, 2015 at 09:13:52AM -0400, Robert Haas wrote:
I think this is a good thing to do, but I sure wish we could go
further and block it completely. That may require
On 4/22/15 9:41 PM, Bruce Momjian wrote:
The case this doesn't catch is referencing a
symbolic link that points to the same directory. We can't make it an
error so people can use pg_upgrade these setups.
Couldn't we make it an ERROR unless IsBinaryUpgrade?
--
Jim Nasby, Data Architect, Blue
On 2015-04-23 11:00:43 -0400, Bruce Momjian wrote:
On Thu, Apr 23, 2015 at 09:13:52AM -0400, Robert Haas wrote:
I think this is a good thing to do, but I sure wish we could go
further and block it completely. That may require more thought than
we have time to put in at this stage of the
On 2015-04-23 15:17:55 -0500, Jim Nasby wrote:
Yes, but only after creating a brand new cluster from scratch, which would
then disallow them from putting tablespaces in $PGDATA.
pg_dumpall output includes tablespaces.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 4/23/15 4:30 PM, Andres Freund wrote:
On 2015-04-23 16:26:09 -0400, Robert Haas wrote:
But pg_upgrade automates all that, so you can't use pg_upgrade in that
case. If we add a GUC as I suggested, you can still use pg_upgrade.
But we also have to live with data directories being in a shit
On Thu, Apr 23, 2015 at 11:00 AM, Bruce Momjian br...@momjian.us wrote:
I have developed the attached patch to warn about creating tablespaces
inside the data directory. The case this doesn't catch is referencing a
symbolic link that points to the same directory. We can't make it an
On 2015-04-23 15:46:20 -0400, Robert Haas wrote:
Well, we've made backward-incompatible changes before. Not to this
specific thing, but in general. I don't think there's anything
preventing us from doing so here, except that we don't want to annoy
too many users.
I think the number of users
On 4/23/15 11:01 AM, Andres Freund wrote:
On April 23, 2015 6:12:05 PM GMT+03:00, Jim Nasby jim.na...@bluetreble.com
wrote:
On 4/22/15 9:41 PM, Bruce Momjian wrote:
The case this doesn't catch is referencing a
symbolic link that points to the same directory. We can't make it an
error so
On 2015-04-23 16:26:09 -0400, Robert Haas wrote:
But pg_upgrade automates all that, so you can't use pg_upgrade in that
case. If we add a GUC as I suggested, you can still use pg_upgrade.
But we also have to live with data directories being in a shit state
forever onward. We won't really be
On Thu, Apr 23, 2015 at 3:57 PM, Andres Freund and...@anarazel.de wrote:
On 2015-04-23 15:46:20 -0400, Robert Haas wrote:
Well, we've made backward-incompatible changes before. Not to this
specific thing, but in general. I don't think there's anything
preventing us from doing so here, except
On Wed, Apr 22, 2015 at 10:41 PM, Bruce Momjian br...@momjian.us wrote:
What is a real problem is that we don't block creating tablespaces
anywhere at all, including in obviously problematic places like the
transaction log directory:
josh=# create tablespace tbl2 location
On Fri, Jan 30, 2015 at 01:26:22PM -0800, Josh Berkus wrote:
Robert, Stephen, etc.:
Apparently you can create a tablespace in the tablespace directory:
josh=# create tablespace tbl location '/home/josh/pg94/data/pg_tblspc/';
CREATE TABLESPACE
josh=# create table test_tbl ( test text )
it is just as likely they simply are not aware
of the downsides and the only reason they put it is $PGDATA is that
it seemed like a logical place to put a directory that is intended to hold
database data.
Yes, this is the reason why we got in this issue. The name PGDATA is misleading.
The
On Fri, Jan 30, 2015 at 11:12:43AM -0500, Robert Haas wrote:
I think everyone who has read this mailing list for a while is
probably already aware of this problem. When you create a tablespace
somewhere inside the data directory, weird things happen. If you
pg_upgrade and then incautiously
On 01/30/2015 08:19 AM, Bruce Momjian wrote:
On Fri, Jan 30, 2015 at 11:12:43AM -0500, Robert Haas wrote:
I think everyone who has read this mailing list for a while is
probably already aware of this problem. When you create a tablespace
somewhere inside the data directory, weird things
* Robert Haas (robertmh...@gmail.com) wrote:
Given all this, it seems like a good idea to at least give a warning
if somebody tries to create a tablespace instead the data directory.
A warning seems like a good idea. I actually thought we *did* prevent
it..
Arguably, we should prohibit it
I think everyone who has read this mailing list for a while is
probably already aware of this problem. When you create a tablespace
somewhere inside the data directory, weird things happen. If you
pg_upgrade and then incautiously run the delete_old_cluster.sh script
thus created, you will blow
On Fri, Jan 30, 2015 at 11:43 AM, Joshua D. Drake j...@commandprompt.com
wrote:
I mean yes a warning is good but it is after the fact, the tablespace is
already created. We know that tablespaces in $PGDATA are a bad idea, why not
protect the user?
Please go back and read the discussion of
On 1/30/15 11:43 AM, Joshua D. Drake wrote:
On 01/30/2015 08:19 AM, Bruce Momjian wrote:
On Fri, Jan 30, 2015 at 11:12:43AM -0500, Robert Haas wrote:
I think everyone who has read this mailing list for a while is
probably already aware of this problem. When you create a tablespace
somewhere
Robert, Stephen, etc.:
Apparently you can create a tablespace in the tablespace directory:
josh=# create tablespace tbl location '/home/josh/pg94/data/pg_tblspc/';
CREATE TABLESPACE
josh=# create table test_tbl ( test text ) tablespace tbl;
CREATE TABLE
josh=# \q
Robert Haas wrote
Arguably, we should prohibit it altogether, but there are obviously
people that want to do it, and there could even be somewhat valid
reasons for that,
Lots of hand-waving here and it is just as likely they simply are not aware
of the downsides and the only reason they put
On 01/30/2015 09:19 AM, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Given all this, it seems like a good idea to at least give a warning
if somebody tries to create a tablespace instead the data directory.
A warning seems like a good idea. I actually thought we *did*
On Mon, Dec 3, 2012 at 10:06 PM, Bruce Momjian br...@momjian.us wrote:
FYI, someone put their new cluster inside an existing old tablespace,
and when they ran the script to delete their old install, their new
install was deleted too. My answer was, Don't do that.
Uh, wow. I feel bad for that
On Tue, Dec 4, 2012 at 09:37:46AM -0500, Robert Haas wrote:
On Mon, Dec 3, 2012 at 10:06 PM, Bruce Momjian br...@momjian.us wrote:
FYI, someone put their new cluster inside an existing old tablespace,
and when they ran the script to delete their old install, their new
install was deleted
On 2012-12-01 14:45, Magnus Hagander wrote:
Someone just reported a problem when they had created a new tablespace
inside the old data directory. I'm sure there can be other issues
caused by this as well, but this is mainly a confusing scenario for
people now.
As there isn't (as far as I know
On Mon, Dec 03, 2012 at 01:14:30PM -0500, Andrew Dunstan wrote:
I think it would be reasonable for it to complain if it came across a
PG_VERSION file in an unexpected location.
That sounds like a reliable approach to detecting the hazard. Pseudocode:
chdir(proposed_tablespace_path)
On Dec 3, 2012 2:55 AM, Andrew Dunstan and...@dunslane.net wrote:
On 12/02/2012 07:50 PM, Magnus Hagander wrote:
On Sat, Dec 1, 2012 at 6:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Someone just reported a problem when they had created a new
On 12/03/2012 12:33 PM, Magnus Hagander wrote:
On Dec 3, 2012 2:55 AM, Andrew Dunstan and...@dunslane.net
mailto:and...@dunslane.net wrote:
On 12/02/2012 07:50 PM, Magnus Hagander wrote:
On Sat, Dec 1, 2012 at 6:56 PM, Tom Lane t...@sss.pgh.pa.us
mailto:t...@sss.pgh.pa.us wrote:
On Mon, Dec 3, 2012 at 02:38:20AM -, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
As there isn't (as far as I know at least) any actual *point* in
creating a tablespace inside the main data directory, should we
perhaps disallow this in CREATE
On Dec 3, 2012, at 12:33, Magnus Hagander wrote:
On Dec 3, 2012 2:55 AM, Andrew Dunstan and...@dunslane.net wrote:
On 12/02/2012 07:50 PM, Magnus Hagander wrote:
On Sat, Dec 1, 2012 at 6:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Someone
On Sat, Dec 1, 2012 at 6:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Someone just reported a problem when they had created a new tablespace
inside the old data directory. I'm sure there can be other issues
caused by this as well, but this is mainly a
On 12/02/2012 07:50 PM, Magnus Hagander wrote:
On Sat, Dec 1, 2012 at 6:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Someone just reported a problem when they had created a new tablespace
inside the old data directory. I'm sure there can be other
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
As there isn't (as far as I know at least) any actual *point* in
creating a tablespace inside the main data directory, should we
perhaps disallow this in CREATE TABLESPACE? Or at least throw a
WARNING if one does it?
Sure there is a point
Someone just reported a problem when they had created a new tablespace
inside the old data directory. I'm sure there can be other issues
caused by this as well, but this is mainly a confusing scenario for
people now.
As there isn't (as far as I know at least) any actual *point* in
creating a
On 1 December 2012 13:45, Magnus Hagander mag...@hagander.net wrote:
Someone just reported a problem when they had created a new tablespace
inside the old data directory. I'm sure there can be other issues
caused by this as well, but this is mainly a confusing scenario for
people now.
As
Magnus Hagander mag...@hagander.net writes:
Someone just reported a problem when they had created a new tablespace
inside the old data directory. I'm sure there can be other issues
caused by this as well, but this is mainly a confusing scenario for
people now.
As there isn't (as far as I
Hi,
I've decided to start hacking on PostgreSQL, and I've looked at the
easier jobs in the TODO list. I'm interested in implementing:
% Add a GUC variable to control the tablespace for temporary objects and sort
files. It could start with a random tablespace from a supplied list and
On Tue, Sep 19, 2006 at 01:10:48AM +0200, Albert Cervera Areny wrote:
Hi,
I've decided to start hacking on PostgreSQL, and I've looked at the
easier jobs in the TODO list. I'm interested in implementing:
% Add a GUC variable to control the tablespace for temporary objects and sort
On Wed, 29 Mar 2006 08:46 am, Philip Yarra wrote:
OK, how about on \d+, if the object is not on pg_default or pg_global,
print the tablespace that this object is on? That way, people not using
tablespaces won't ever see it.
Tom, does this answer your objection? If so, I'll produce a patch for
On Wed, 29 Mar 2006 08:46 am, Philip Yarra wrote:
OK, how about on \d+, if the object is not on pg_default or pg_global,
print the tablespace that this object is on? That way, people not using
tablespaces won't ever see it.
Tom, does this answer your objection? If so, I'll produce a patch for
Philip Yarra [EMAIL PROTECTED] writes:
Someone else might be able to see a better way to write this query, but I
think it would be good if \d could show this information, when you really
want to know which tablespace an object is on.
If \d doesn't say anything then the table is in the
On Wed, 29 Mar 2006 01:36 am, Tom Lane wrote:
Philip Yarra [EMAIL PROTECTED] writes:
Someone else might be able to see a better way to write this query, but I
think it would be good if \d could show this information, when you really
want to know which tablespace an object is on.
If \d
Hi folks after discussing this on IRC today (thanks G_SabinoMullane!), I'm
still surprised by this behaviour on 8.1.3:
pyarra=# create TABLESPACE spctables location '/mnt/pg_tables/data';
CREATE TABLESPACE
pyarra=# create table foo(id int) tablespace spctables;
CREATE TABLE
pyarra=# \d foo
Gavin Sherry wrote:
Related question: are there plans afoot to allow specifying an alternate
location for pg_xlog (or pg_delete-me-not) to save doing the shutdown-DB, mv
directory to other disk, symlink, start-DB dance?
People have discussed it but I don't know of anyone working on it.
On Tue, Nov 22, 2005 at 01:38:34PM -0500, Bruce Momjian wrote:
Gavin Sherry wrote:
Related question: are there plans afoot to allow specifying an alternate
location for pg_xlog (or pg_delete-me-not) to save doing the shutdown-DB,
mv
directory to other disk, symlink, start-DB dance?
On Tue, 22 Nov 2005, Jim C. Nasby wrote:
On Tue, Nov 22, 2005 at 01:38:34PM -0500, Bruce Momjian wrote:
Gavin Sherry wrote:
Related question: are there plans afoot to allow specifying an alternate
location for pg_xlog (or pg_delete-me-not) to save doing the
shutdown-DB, mv
Jim C. Nasby wrote:
On Tue, Nov 22, 2005 at 01:38:34PM -0500, Bruce Momjian wrote:
* Allow the pg_xlog directory location to be specified during initdb
with a symlink back to the /data location
I think the only reason it is not done yet is because it is so easy to
do for
On Wed, 23 Nov 2005 11:23 am, Gavin Sherry wrote:
Along those lines, is there anything else that would benefit from being
moved? pg_clog and pg_subtrans come to mind; but maybe pg_multixact and
pg_twophase are candidates as well?
pgsql_tmp
Does anyone have any recommendations about which
Alvaro Herrera [EMAIL PROTECTED] writes:
Jim C. Nasby wrote:
Along those lines, is there anything else that would benefit from being
moved? pg_clog and pg_subtrans come to mind; but maybe pg_multixact and
pg_twophase are candidates as well?
Hmm, I doubt moving any of the SLRU files (clog,
This is because lost+found exists. Since lost+found would be a
reasonably common directory to find at a mount-point on Unix-like
OSs*, would it make sense for CREATE TABLESPACE to ignore it if
present?
No. There is no reason to use a volume's root directory as a
tablespace;
especially
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes:
No. There is no reason to use a volume's root directory as a
tablespace;
especially so since the root directory ought to be owned by root
That is not so on AIX. Only the moint point (the dir in the parent) is
root.
Once mounted it can
I assume CREATE TABLESPACE refuses to use a non-empty directory because of the
risk of trashing existing files. Makes sense, but consider the following:
# mkfs -t ext2 /dev/sdc1
# mount -t ext2 /dev/sdc1 /mnt/pg_tables
# chown postgres /mnt/pg_tables
# su -c psql pyarra
pyarra=# CREATE
On Thu, 17 Nov 2005, Philip Yarra wrote:
I assume CREATE TABLESPACE refuses to use a non-empty directory because of the
risk of trashing existing files. Makes sense, but consider the following:
Right, that was the reasoning.
# mkfs -t ext2 /dev/sdc1
# mount -t ext2 /dev/sdc1 /mnt/pg_tables
Philip Yarra [EMAIL PROTECTED] writes:
This is because lost+found exists. Since lost+found would be a reasonably
common directory to find at a mount-point on Unix-like OSs*, would it make
sense for CREATE TABLESPACE to ignore it if present?
No. There is no reason to use a volume's root
Christopher Kings-Lynne wrote:
I'm interested if anyone is using tablespaces? Do we have any actual
reports of people actually using them, to advantage, in the field??
Maybe the next postgresql.org survey could be on tablespace usage?
Chris
I have seen that tablespaces are widely used
On Fri, 2005-06-03 at 08:41 +0200, Hans-Jrgen Schnig wrote:
Christopher Kings-Lynne wrote:
I'm interested if anyone is using tablespaces? Do we have any actual
reports of people actually using them, to advantage, in the field??
Maybe the next postgresql.org survey could be on
On Fri, 2005-06-03 at 11:17 +0800, Christopher Kings-Lynne wrote:
Maybe the next postgresql.org survey could be on tablespace usage?
Could we plan a more comprehensive survey, with more than one question?
Judging by the number of people who fill out surveys, we would still get
thousands of
I'm interested if anyone is using tablespaces? Do we have any actual
reports of people actually using them, to advantage, in the field??
Maybe the next postgresql.org survey could be on tablespace usage?
Chris
---(end of broadcast)---
TIP 9:
Bruce Momjian [EMAIL PROTECTED] writes:
Greg Stark wrote:
Actually the sort algorithm postgres uses would be much more efficient if it
could get access to two or three locations guaranteed to be on different
spindles.
Agreed, and I was going to mention the idea of a round-robin allocation
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Greg Stark wrote:
Actually the sort algorithm postgres uses would be much more efficient if it
could get access to two or three locations guaranteed to be on different
spindles.
Agreed, and I was going to mention the idea of a
Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
On the whole I'm unconvinced that this is worth the trouble. One of the
reasons for allowing people to move databases around is to determine
where their temp files go.
The one scenario I would expect to see is having the temp
Tom Lane [EMAIL PROTECTED] writes:
On the whole I'm unconvinced that this is worth the trouble. One of the
reasons for allowing people to move databases around is to determine
where their temp files go.
The one scenario I would expect to see is having the temp files on filesystem
all to
On Sat, 2004-10-30 at 00:50, Tom Lane wrote:
(1) What are the protection requirements for this variable?
I think it can be USERSET -- most commands let the user specify a
tablespace explicitly, and this is basically just another way of doing
that. The user executing the query will need CREATE
So I'd like to add a GUC variable called something like
scratch_tablespace. If undefined (the default), temporary files for
Should be called 'work_tablesapce' to match 'work_mem' :)
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands
Neil Conway [EMAIL PROTECTED] writes:
So I'd like to add a GUC variable called something like
scratch_tablespace. If undefined (the default), temporary files for
sorting/etc. will be created in the current database's tablespace.
(1) What are the protection requirements for this variable?
(2)
I'd like to provide a way for DBAs to specify that the temporary files
needed to for sorting, holdable cursors and similar operations should be
created in a particular tablespace. (Right now these files are created
in the tablespace associated with the current database.)
Two ways to do this come
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
I surely hope not. Especially not multi-gig databases. The folks
running
those should know better than to use Windows, and if they do not,
I'll
be happy to tell them so.
You know, it makes you wonder.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
I surely hope not. Especially not multi-gig databases. The folks running
those should know better than to use Windows, and if they do not, I'll
be happy to tell them so.
You know, it makes you wonder.
Tom Lane wrote:
Dann Corbit [EMAIL PROTECTED] writes:
I expect that one year after release, there will be ten times as many
PostgreSQL systems on Win32 as all combined versions now on UNIX flavors
I surely hope not. Especially not multi-gig databases. The folks
running those should know
With the rule system and two underlying tables one could make it work by
hand I think.
The rule system could be used to do this, but there was some discussion of
using inherited tables to handle it. However neither handles the really hard
part of detecting queries that use only a part
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
e.g if you have a constraint acol integer, check acol 5
and you have a query with a where acol = 10 you could reduce that
to where false.
I think part of the question is how much work do you put into checking this.
Checking constant known
I don't think we want features for their own sake, though, and I'm
not convinced that raw filesystems are actually useful. Course, it's
not my itch, and PostgreSQL _is_ free software.
I agree that raw file systems are seldom useful with one caveat, more
advanced file systems are sometimes
Dann Corbit [EMAIL PROTECTED] writes:
I expect that one year after release, there will be ten times as many
PostgreSQL systems on Win32 as all combined versions now on UNIX flavors
I surely hope not. Especially not multi-gig databases. The folks
running those should know better than to use
Subject: Re: [pgsql-hackers-win32] [HACKERS] Tablespaces
Dann Corbit [EMAIL PROTECTED] writes:
I expect that one year after release, there will be ten
times as many
PostgreSQL systems on Win32 as all combined versions now on UNIX
flavors
I surely hope not. Especially not multi-gig
: Re: [pgsql-hackers-win32] [HACKERS] Tablespaces
Dann Corbit [EMAIL PROTECTED] writes:
I expect that one year after release, there will be ten
times as many
PostgreSQL systems on Win32 as all combined versions now on UNIX
flavors
I surely hope not. Especially not multi-gig databases
Subject: RE: [pgsql-hackers-win32] [HACKERS] Tablespaces
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, June 11, 2004 9:39 AM
To: Tom Lane
Cc: Dann Corbit; Zeugswetter Andreas SB SD; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Bruce Momjian; Greg
We should provide people with the right tools, true, but we
are bound by our conscience to inform them about Windows' failures.
It must be nice to be young and still see everything as black and white
with no shades of gray.
I wouldn't call 41 very young.
For those who think that Windows
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, June 11, 2004 2:41 PM
To: Dann Corbit
Cc: [EMAIL PROTECTED]; PostgreSQL Win32 port list
Subject: RE: [pgsql-hackers-win32] [HACKERS] Tablespaces
[snip]
Microsoft has harmed the computing industry
[EMAIL PROTECTED] wrote:
We should provide people with the right tools, true, but we
are bound by our conscience to inform them about Windows' failures.
It must be nice to be young and still see everything as black and white
with no shades of gray.
I wouldn't call 41 very young.
; [EMAIL PROTECTED]; PostgreSQL Win32 port list
Subject: Re: [pgsql-hackers-win32] [HACKERS] Tablespaces
Dann Corbit [EMAIL PROTECTED] writes:
I expect that one year after release, there will be ten
times as many
PostgreSQL systems on Win32 as all combined versions now on UNIX
[EMAIL PROTECTED] wrote:
Actually, I am not a wide eyed passionate Linux zealot. Like my support
for John Kerry, I gladly choose the better side of mediocrity over extream
evil, it is nothing more than pure practicality.
I don't like dubya either, but he isn't extreme evil. This sort of
Having been a Windows developer since version 1.03, with DOS
and CP/M before that, I can say with complete authority that
most Windows developers are not good. The worst I've seen
is Charles Petzold, and he sets the bar.
Charles Petzold is a decent programmer. I have read his books and he
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
My feeling is that we need not support tablespaces on OS's without
symlinks.
Agreed, but are we going to support non-tablespace installs? I wasn't
sure that was an option.
A setup containing only the default tablespace cannot use any
Thomas Swan [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
The advantage of symlinks is that an administrator could see how things
are laid out from the command line.
That's a poor reason to require symlinks. The administrator can just as
easily open up psql and query pg_tablespace to see
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
My feeling is that we need not support tablespaces on OS's without
symlinks.
To create symlinked directories on Win2k NTFS see:
http://www.sysinternals.com/ntw2k/source/misc.shtml#junction
I think Win2000 or XP would be a reasonable
Subject: Re: [pgsql-hackers-win32] [HACKERS] Tablespaces
First of all, symlinks are a pretty popular feature.
Even Windows
supports what would be needed. Second of all, PostgreSQL
will still
run on OSes without symlinks, tablespaces won't be available, but
PostgreSQL will still run
Dann Corbit [EMAIL PROTECTED] writes:
I expect that one year after release, there will be ten times as many
PostgreSQL systems on Win32 as all combined versions now on UNIX flavors
I surely hope not. Especially not multi-gig databases. The folks
running those should know better than to use
Gavin,
#1: I really think that we should have a way to set a default tablespace
for any database in a cluster. This property would be vitally important
for anyone wishing to use tablespaces to impose quotas. First, the
superuser would:
ALTER DATABASE db1 ALTER DEFAULT_TABLESPACE
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Thu, 26 Feb 2004, Gavin Sherry wrote:
Comments? Questions? Suggestions?
Is that plan that in the future one can split a single table into
different table spaces? Like storing all rows with year 1999 in one
tablespace and the rest in
On Thu, 26 Feb 2004, Gavin Sherry wrote:
Comments? Questions? Suggestions?
Is that plan that in the future one can split a single table into
different table spaces? Like storing all rows with year 1999 in one
tablespace and the rest in another?
With the rule system and two underlying tables
scott.marlowe [EMAIL PROTECTED] writes:
On Fri, 27 Feb 2004, Tom Lane wrote:
In my mind, one of the main benefits of this work will be that we'll be
able to get *rid* of the initlocation stuff. It's a crock.
OK, that's fine, but I keep thinking that a superuser should have to
create the
On Fri, 2004-05-28 at 08:15, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
You are absolutely wrong on all accounts here. A RAID5 system is slower
than a single spindle as it is only as fast as the slowest disk in the
stripe and the overhead of the RAID.
Huh, what kind of controller
[EMAIL PROTECTED] wrote:
As for IDE RAID, IDE RAID is an awesome idea. SCSI disks are just too
expensive. Infortrend has a cool IDE to SCSI or Fibre RAID system that
rocks.
Obviously, you're caught by those marketing geeks. You're taking
bandwidth (MB/s)as performance index, which is
[EMAIL PROTECTED] wrote:
As for IDE RAID, IDE RAID is an awesome idea. SCSI disks are just too
expensive. Infortrend has a cool IDE to SCSI or Fibre RAID system that
rocks.
Obviously, you're caught by those marketing geeks. You're taking
bandwidth (MB/s)as performance index, which is
1 - 100 of 208 matches
Mail list logo
