Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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 - actua

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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 these

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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 inconveni

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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 c

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

On Thu, Apr 23, 2015 at 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 director

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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 a

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

On Thu, Apr 23, 2015 at 3:57 PM, Andres Freund 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 that we don

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

On 4/23/15 11:01 AM, Andres Freund wrote: On April 23, 2015 6:12:05 PM GMT+03:00, Jim Nasby 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 people can use pg_upgrade the

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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 us

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

On Thu, Apr 23, 2015 at 11:00 AM, Bruce Momjian 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 >> > error so

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

On April 23, 2015 6:12:05 PM GMT+03:00, Jim Nasby 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 people can use pg_upgrade these setups. > >Couldn't we make it an

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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 Tr

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

On Thu, Apr 23, 2015 at 09:13:52AM -0400, Robert Haas wrote: > On Wed, Apr 22, 2015 at 10:41 PM, Bruce Momjian 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: > >

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

On Wed, Apr 22, 2015 at 10:41 PM, Bruce Momjian 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 '/home/josh/pg94/data/pg_xl

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

> 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. > T

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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 josh@Radegast:~/pg94/data/pg_tbls

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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 *

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

* 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

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

On Fri, Jan 30, 2015 at 11:43 AM, Joshua D. Drake 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 that option in the OP.

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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 happe

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

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

[HACKERS] tablespaces inside $PGDATA considered harmful

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 awa

Re: [HACKERS] Tablespaces in the data directory

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)

Re: [HACKERS] Tablespaces in the data directory

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 at

Re: [HACKERS] Tablespaces in the data directory

On Tue, Dec 4, 2012 at 09:37:46AM -0500, Robert Haas wrote: > On Mon, Dec 3, 2012 at 10:06 PM, Bruce Momjian 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 an

Re: [HACKERS] Tablespaces in the data directory

On Mon, Dec 3, 2012 at 10:06 PM, Bruce Momjian 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 person, but

Re: [HACKERS] Tablespaces in the data directory

On Dec 3, 2012, at 12:33, Magnus Hagander wrote: > On Dec 3, 2012 2:55 AM, "Andrew Dunstan" wrote: >> >> >> On 12/02/2012 07:50 PM, Magnus Hagander wrote: >>> >>> On Sat, Dec 1, 2012 at 6:56 PM, Tom Lane wrote: Magnus Hagander writes: > > Someone just reported a problem

Re: [HACKERS] Tablespaces in the data directory

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

Re: [HACKERS] Tablespaces in the data directory

On 12/03/2012 12:33 PM, Magnus Hagander wrote: On Dec 3, 2012 2:55 AM, "Andrew Dunstan" > wrote: > > > On 12/02/2012 07:50 PM, Magnus Hagander wrote: >> >> On Sat, Dec 1, 2012 at 6:56 PM, Tom Lane > wrote: >>> >>> Magnus Hagander mailto:

Re: [HACKERS] Tablespaces in the data directory

On Dec 3, 2012 2:55 AM, "Andrew Dunstan" wrote: > > > On 12/02/2012 07:50 PM, Magnus Hagander wrote: >> >> On Sat, Dec 1, 2012 at 6:56 PM, Tom Lane wrote: >>> >>> Magnus Hagander writes: Someone just reported a problem when they had created a new tablespace inside the old data dir

Re: [HACKERS] Tablespaces in the data directory

-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 poi

Re: [HACKERS] Tablespaces in the data directory

On 12/02/2012 07:50 PM, Magnus Hagander wrote: On Sat, Dec 1, 2012 at 6:56 PM, Tom Lane wrote: Magnus Hagander 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

Re: [HACKERS] Tablespaces in the data directory

On Sat, Dec 1, 2012 at 6:56 PM, Tom Lane wrote: > Magnus Hagander 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

Re: [HACKERS] Tablespaces in the data directory

Magnus Hagander 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 know at least) any

Re: [HACKERS] Tablespaces in the data directory

On 1 December 2012 13: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 f

[HACKERS] Tablespaces in the data directory

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 table

Re: [HACKERS] Tablespaces for temporary objects

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 so

[HACKERS] Tablespaces for temporary objects

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 cycl

Re: [HACKERS] Tablespaces oddity?

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 fo

Re: [HACKERS] Tablespaces oddity?

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 fo

Re: [HACKERS] Tablespaces oddity?

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. > >

Re: [HACKERS] Tablespaces oddity?

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 d

[HACKERS] Tablespaces oddity?

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

Re: [HACKERS] tablespaces and non-empty directories

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

Re: [HACKERS] tablespaces and non-empty directories

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

Re: [HACKERS] tablespaces and non-empty directories

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

Re: [HACKERS] tablespaces and non-empty directories

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-

Re: [HACKERS] tablespaces and non-empty directories

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

Re: [HACKERS] tablespaces and non-empty directories

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

Re: [HACKERS] tablespaces and non-empty directories

"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 mount

Re: [HACKERS] tablespaces and non-empty directories

> > 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; > esp

Re: [HACKERS] tablespaces and non-empty directories

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

Re: [HACKERS] tablespaces and non-empty directories

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_ta

[HACKERS] tablespaces and non-empty directories

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 TABLESPACE

Re: [HACKERS] Tablespaces

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 repl

Re: [HACKERS] Tablespaces

On Fri, 2005-06-03 at 08:41 +0200, Hans-Jürgen Schönig 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

Re: [HACKERS] Tablespaces

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 and

[HACKERS] Tablespaces

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:

Re: [HACKERS] tablespaces for temporary files

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

Re: [HACKERS] tablespaces for temporary files

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 allo

Re: [HACKERS] tablespaces for temporary files

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

Re: [HACKERS] tablespaces for temporary files

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

Re: [HACKERS] tablespaces for temporary files

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 pr

Re: [HACKERS] tablespaces for temporary files

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?

Re: [HACKERS] tablespaces for temporary files

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

[HACKERS] tablespaces for temporary files

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 t

Re: [pgsql-hackers-win32] [HACKERS] Tablespaces

> >> > -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

Re: [pgsql-hackers-win32] [HACKERS] Tablespaces

> > -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

Re: [pgsql-hackers-win32] [HACKERS] Tablespaces

>> >> 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

Re: [pgsql-hackers-win32] [HACKERS] Tablespaces

[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 argum

Re: [pgsql-hackers-win32] [HACKERS] Tablespaces

D]; [EMAIL PROTECTED]; Bruce Momjian; Greg > > Stark; [EMAIL PROTECTED]; PostgreSQL Win32 port list > > Subject: Re: [pgsql-hackers-win32] [HACKERS] Tablespaces > > > > > > > "Dann Corbit" <[EMAIL PROTECTED]> writes: > > >> I expect that

Re: [pgsql-hackers-win32] [HACKERS] Tablespaces

[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

Re: [pgsql-hackers-win32] [HACKERS] Tablespaces

> -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

Re: [pgsql-hackers-win32] [HACKERS] Tablespaces

>> >> 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

Re: [pgsql-hackers-win32] [HACKERS] Tablespaces

reSQL Win32 port list > 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 > >>

Re: [pgsql-hackers-win32] [HACKERS] Tablespaces

; [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

Re: [pgsql-hackers-win32] [HACKERS] Tablespaces

reSQL 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

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. The folks > running those should know better

Re: [HACKERS] Tablespaces

> 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 sometime

Re: [HACKERS] Tablespaces

"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 c

Re: [HACKERS] Tablespaces

> > 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

Re: [pgsql-hackers-win32] [HACKERS] Tablespaces

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 kn

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. The folks running those should know better than to u

Re: [pgsql-hackers-win32] [HACKERS] Tablespaces

]; PostgreSQL Win32 port list > 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 >

Re: [pgsql-hackers-win32] [HACKERS] Tablespaces

> "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 wo

Re: [HACKERS] Tablespaces

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_tablespa

Re: [pgsql-hackers-win32] [HACKERS] Tablespaces

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

Re: [HACKERS] Tablespaces

Gavin Sherry <[EMAIL PROTECTED]> writes: > I was trying to be paranoid about users who have multiple postmasters on > the same machine and want to share a table space while both systems are > live. There'd be no mechanism to test for that situation if we didn't have > something like a postmaster.pi

Re: [HACKERS] Tablespaces

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 re

Re: [HACKERS] Tablespaces

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 partiti

Re: [HACKERS] Tablespaces

"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 > cre

Re: [HACKERS] Tablespaces

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 table

Re: [HACKERS] tablespaces and DB administration

> [EMAIL PROTECTED] wrote: > >> >>What you are missing is that the RAID is dealing with the multiple drives >>as one drive. Two operations have to happen serially, >> > > You're kidding or vastly underestimating raid controllers. The average > db access is well served with a single block of data, s

  1   2   3   >