Re: [HACKERS] pgsql-server: Tablespaces.
Hm ... seems like that requires more special cases, not fewer. What I was imagining was the current database-local pg_description plus a single shared table pg_shared_description. When you add more kinds of shared objects (SQL roles maybe?) obj_description doesn't need to change... Oh yeah, that's a much better idea :) Didn't think of that :) Chris ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Twelve days to feature freeze
-Original Message- From: [EMAIL PROTECTED] on behalf of Bruce Momjian Sent: Sat 6/19/2004 4:18 AM To: PostgreSQL-development Subject: [HACKERS] Twelve days to feature freeze Win32 - need service manger code, Claudio posted a patch for that that looked OK. I haven't had a chance to properly test it yet though - hopefully tonight. installer is outside project Magnus I (well, mainly Magnus) have been working on that. Most of it's there now :-) Regards, Dave ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Cannot initdb in cvs tip
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Sat 6/19/2004 12:21 AM To: Dave Page Cc: PostgreSQL-development Subject: Re: [HACKERS] Cannot initdb in cvs tip The target block number is obviously broken :-(. But maybe you have a build consistency problem --- did you try a make distclean and full rebuild? No, I was having trouble keeping my eyes open by then. I'll give it a go tonight. Hm. The rmtree() function in initdb.c is responsible for this, and I see it has WIN32-specific behavior, which is evidently wrong. Can you recommend a fix? I'll take a look at this. Regards, Dave ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] OWNER TO on all objects
Any change someone who knows (or who can declare that we not fix existing dumps) comment on this? Chris Christopher Kings-Lynne wrote: I think this is wrong, primarily because it's gonna be seriously incompatible with existing dump files. The existing technique is that each TOC entry says who owns the object. You should use that information and not have to rely on new additions to the file format. This is why GRANT/REVOKE has to be postponed to the end. I think it would be a lot simpler and more reliable if you also postponed ALTER OWNER. OK, implementing this is nasty. How do I collect up all the ACLs from EXISTING custom archives and move them to the end?? This is hard because ACLs are just dependents on their parent object and cannot be sorted on their own to the end of the dump. Since the dumping process outputs to stdout as it goes along, I'd have to create some big in-memory string of all acls and owners collected so far. That seems bad. The alternative is to scan the entire archive twice. On the second scan I would only output owner and acl commands. Another option is to simply not bother fixing old custom dumps. They could just still restore exactly how they would have without any changes from me. I would add new TOC types to the 7.5 pg_dump that could be sorted to the end... What do I do? Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Compilation failes in CVS tip
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I've made a fresh checkout from CVS and getting the following error. Platform is RHEL 3 with [EMAIL PROTECTED] pgsql]$ gcc -v ... gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-24) == make -C interfaces all make[2]: Entering directory `/home/pgsql75/pgsql/src/interfaces' make[3]: Entering directory `/home/pgsql75/pgsql/src/interfaces/libpq' Makefile:75: *** invalid syntax in conditional. Stop. make[3]: Leaving directory `/home/pgsql75/pgsql/src/interfaces/libpq' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/pgsql75/pgsql/src/interfaces' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/pgsql75/pgsql/src' make: *** [all] Error 2 == Below are the relevant lines in /home/pgsql75/pgsql/src/interfaces/libpq/Makefile: == ifeq ($(PTHREAD_H_WIN32)) pthread.h : % : $(top_srcdir)/src/interfaces/libpq/pthread.h.win rm -f $@ $(LN_S) $ . endif == Any commments? Regards, - -- Devrim GUNDUZ devrim~gunduz.org devrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA1ANQtl86P3SPfQ4RAra7AJsFk4ZCguSMNrEdp57XPO1VTprthACfeT8C VmNWZ8AvLNJ00J9mT/ZVMQ0= =8tuI -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] logfile rotation
Bruce Momjian wrote: Actually, this is the current state of this issue. Right, please comment on this. To recall, it uses shared memory for a switch to next logfile name flag, which can't cause harm in case of shmem corruption, and a postmaster opened filehandle (kept open) to a dummy file containing the actual file name (pseudo code below). Regards, Andreas --- Andreas Pflug wrote: Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: Answering my own question, the distribution of the current logfile name could be done trough a file handle. would you mind commenting on my suggestion so I can continue on that topic? There is no portable way to redistribute a file handle. Seems I didn't make clear enough what I mean. I'd fopen a file handle in the postmaster, and all subsequent processes will inherit that handle just as they do for stderr; no redistribution required. The log filename is written to that file when pg_logfile_rotate is called: fseek(fh, 0, SEEK_SET); fprintf(fh, %s, newlogfilname); fflush(); and all subprocesses may retrieve the filename when required by char buf[MAXPGPATH]; fseek(fh, 0, SEEK_SET); fread(buf, 1, MAXPGPATH, fh); buf[MAXPGPATH-1]=0; // prevent buffer overflow logfile=fopen(buf, a+); Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Compilation failes in CVS tip
Devrim GUNDUZ wrote: == Below are the relevant lines in /home/pgsql75/pgsql/src/interfaces/libpq/Makefile: == ifeq ($(PTHREAD_H_WIN32)) pthread.h : % : $(top_srcdir)/src/interfaces/libpq/pthread.h.win rm -f $@ $(LN_S) $ . endif == pthread.h.win is the pthread partial emu for win32 libpq (compilable with win32.mak), which shouldn't be mentioned in Linux Makefile at all (copying to pthread.h would override /usr/include/pthread.h, we don't want that). Might be caused by Bruce's change to the native win32 port. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] ALTER TABLE with Tablespace?
It seems ALTER TABLE does not support table space. I think this is neccessary because: 1) if a data disk if full, users need to move table to another table spaces. 2) if performance hits, users could move the table which is likely a bottle neck to another table space. I know that pg_dump+pg_restore will do the trick, but I think tablespace can handle this better. -- Tatsuo Ishii ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] pgpool 2.0RC1
The new verion of pgpool, yet another open source replication software for PostgreSQL is now in RC1: ftp://ftp.sra.co.jp/pub/cmd/postgres/pgpool/pgpool-2.0RC1.tar.gz pgpool is a single master/query based/synchronous replication server. It acts as a proxy server between PostgreSQL client and PostgreSQL server. No application change is needed to use pgpool. pgpool's features include: o connection pooling. This will reduce the connection establishing overhead. o pre-forking child processes. Like Apache, pgpool pre-forks child processes to provide faster service startup. o degeneration. In the replication mode, if one of PostgreSQL goes down, it detaches the broken server and continues operation with the surviving server. o fail over. In the connection pool server mode, if master PostgreSQL goes down, it detaches the broken server and continues operation with the stand-by server. In addtion to above, 2.0 supports native V3 protocol which should make pgpool faster if used with PostgreSQL 7.4 or later. Also, now pgpool supports the load balancing between master/secondary PostgreSQL backends to gain better performace for SELECT statement. Enjoy, -- Tatsuo Ishii ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ALTER TABLE with Tablespace?
On Sat, 19 Jun 2004, Tatsuo Ishii wrote: It seems ALTER TABLE does not support table space. I think this is neccessary because: 1) if a data disk if full, users need to move table to another table spaces. 2) if performance hits, users could move the table which is likely a bottle neck to another table space. I know that pg_dump+pg_restore will do the trick, but I think tablespace can handle this better. I'm going to try and find some time to do this over the next few days. I figure it will mostly look like cluster() so shouldn't be too time consuming. I agree that it would be very useful, particularly for those upgrading to 7.5 and wanting to make use of tablespaces. Thanks, Gavin ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Twelve days to feature freeze
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I am still hopeful that we can get a significant plperl improvement before feature freeze, including shared data space, set returning funcs, composite returning funcs, triggers and an spi query mechanism. It will be touch and go and we might not make the cut, but i'm going to try. I think we're trying to discourage people from the submit big patch on June 30 mindset. If you've got any chance of making feature freeze then you must have something fairly interesting already. Put up a work-in-progress patch so that you can get some feedback sooner, instead of later. As an example, Alvaro's been putting up WIP patches for nested transactions regularly. I have to admit that I personally have been awful about giving him any feedback, but others have done more. We have a version that works with cvs tip (at least of a day or so ago). See http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/plperlng/plperlng/ - all the features I mentioned are there. Because pgfoundry is having trouble with anoncvs (which I am trying to fix) I have put a dropin replacement for the core cvs plperl directory here: http://pgfoundry.org/download.php/36/plperlng-2004-06-19.tar.gz The reasons for not submitting a patch yet are: that the API is not quite settled (see http://lists.pgfoundry.org/pipermail/plperlng-devel/2004-June/date.html ), that we need to do quite a lot of testing, and that the docs are almost totally nonexistant. Any help or comments will be appreciated. cheers andrew ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Compilation failes in CVS tip
Fix applied. Sorry. --- Andreas Pflug wrote: Devrim GUNDUZ wrote: == Below are the relevant lines in /home/pgsql75/pgsql/src/interfaces/libpq/Makefile: == ifeq ($(PTHREAD_H_WIN32)) pthread.h : % : $(top_srcdir)/src/interfaces/libpq/pthread.h.win rm -f $@ $(LN_S) $ . endif == pthread.h.win is the pthread partial emu for win32 libpq (compilable with win32.mak), which shouldn't be mentioned in Linux Makefile at all (copying to pthread.h would override /usr/include/pthread.h, we don't want that). Might be caused by Bruce's change to the native win32 port. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] email browser?
On Fri, Jun 18, 2004 at 19:21:07 -0600, Scott Marlowe [EMAIL PROTECTED] wrote: On Fri, 2004-06-18 at 08:24, Chris Browne wrote: Santo Quartarone [EMAIL PROTECTED] writes: What's the safest email browser? less is pretty safe, more or less ;-). You didn't specify what sort of platform you wanted to use; the choices vary, considerably, between platforms. I'd say pine is pretty darned safe... While both pine and mutt have had remote exploit bugs in the past, they are probably your safeest alternatives. I prefer mutt as it is more configurable and has a faster to use (IMO) interface than pine. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] Tablespace patch review
[ switching to pghackers for wider comment ] Christopher Kings-Lynne [EMAIL PROTECTED] writes: By the way, I think that we should deny users the ability to create tablespaces that begin with pg_. Also, the existing ones should be pg_global and pg_default. That way, we have room to move if ever we decide we want more system tablespaces. It also makes it easier to dump non-system tablespaces. Seems like a reasonable suggestion to me. Any objections? BTW, another argument for this is that default is a reserved word. I'd already noticed in testing that CREATE TABLE ... TABLESPACE default doesn't work unless you double-quote default. Calling it pg_default would avoid that annoyance. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Tablespace patch review
Tom Lane wrote: [ switching to pghackers for wider comment ] Christopher Kings-Lynne [EMAIL PROTECTED] writes: By the way, I think that we should deny users the ability to create tablespaces that begin with pg_. Also, the existing ones should be pg_global and pg_default. That way, we have room to move if ever we decide we want more system tablespaces. It also makes it easier to dump non-system tablespaces. Seems like a reasonable suggestion to me. Any objections? BTW, another argument for this is that default is a reserved word. I'd already noticed in testing that CREATE TABLE ... TABLESPACE default doesn't work unless you double-quote default. Calling it pg_default would avoid that annoyance. CREATE TABLESPACE DEFAULT with default as keyword seems reasonable too, with default - pg_default. I could think of cases where temporary schemas should go to a different tablespace, but AFAICS since these are created implicitely there's no way to redirect them. Maybe an additional attribute in pg_database for a default temp tablespace is desirable? Regards, Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Cannot initdb in cvs tip
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 19 June 2004 00:22
To: Dave Page
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Cannot initdb in cvs tip
Dave Page [EMAIL PROTECTED] writes:
I'm getting the following error when trying to initdb with CVS tip.
creating template1 database in
C:/msys/1.0/local/pgsql/data/base/1 ...
ERROR: could not open segment 1 of relation 1663/1/1255
(target block
26189776): No such file or directory
The target block number is obviously broken :-(. But maybe
you have a build consistency problem --- did you try a make
distclean and full rebuild?
OK, that cured that one - thanks.
although it says it's clearing the contents of the directory, in
actual fact it leaves the directory structure in place, thus a
subsequent initdb will not run without a manual clearup.
Hm. The rmtree() function in initdb.c is responsible for
this, and I see it has WIN32-specific behavior, which is
evidently wrong.
Can you recommend a fix?
The current solution does an rmdir /q /s $PGDATA if the datadir was
created, and del /q /s $PGDATA if the directory already existed. The
second case will not work, as del will not remove directories. AFAICS,
there is no easy way to do this using system() as rmdir won't accept
wildcards, so we can't do del $PGDATA/* rmdir $PGDATA/*.
It seems to me that the simple answer is to put Andrew's recursive
unlink code back in (as he suggested), which Bruce removed as rm etc.
were being used in commands/dbcommands.c (which should work fine under
Windows). Patch below
Regards, Dave
*** initdb.c.orig Sat Jun 19 22:15:28 2004
--- initdb.cSat Jun 19 23:02:10 2004
***
*** 132,137
--- 132,144
static void *xmalloc(size_t size);
static char *xstrdup(const char *s);
static bool rmtree(char *path, bool rmtopdir);
+
+ #ifdef WIN32
+ static int init_unlink(const char *);
+ #else
+ #define init_unlink(x) unlink( (x) )
+ #endif /* WIN32 */
+
static char **replace_token(char **lines, char *token, char
*replacement);
static char **readfile(char *path);
static void writefile(char *path, char **lines);
***
*** 245,264
static bool
rmtree(char *path, bool rmtopdir)
{
! charbuf[MAXPGPATH + 64];
! #ifndef WIN32
! /* doesn't handle .* files, but we don't make any... */
! snprintf(buf, sizeof(buf), rm -rf \%s\%s, path,
!rmtopdir ? : /*);
! #else
! snprintf(buf, sizeof(buf), %s /s /q \%s\,
!rmtopdir ? rmdir : del, path);
! #endif
! return !system(buf);
}
/*
* make a copy of the array of lines, with token replaced by
replacement
--- 252,349
static bool
rmtree(char *path, bool rmtopdir)
{
! charfilepath[MAXPGPATH];
! DIR*dir;
! struct dirent *file;
! char **filenames;
! char **filename;
! int numnames = 0;
! struct stat statbuf;
! /*
!* we copy all the names out of the directory before we start
modifying
!* it.
!*
!*/
!
! dir = opendir(path);
! if (dir == NULL)
! return false;
! while ((file = readdir(dir)) != NULL)
! {
! if (strcmp(file-d_name, .) != 0
strcmp(file-d_name, ..) != 0)
! numnames++;
! }
!
! rewinddir(dir);
!
! filenames = xmalloc((numnames + 2) * sizeof(char *));
! numnames = 0;
!
! while ((file = readdir(dir)) != NULL)
! {
! if (strcmp(file-d_name, .) != 0
strcmp(file-d_name, ..) != 0)
! filenames[numnames++] = xstrdup(file-d_name);
! }
!
! filenames[numnames] = NULL;
!
! closedir(dir);
!
! /* now we have the names we can start removing things */
!
! for (filename = filenames; *filename; filename++)
! {
! snprintf(filepath, MAXPGPATH, %s/%s, path, *filename);
!
! if (stat(filepath, statbuf) != 0)
! return false;
!
! if (S_ISDIR(statbuf.st_mode))
! {
! /* call ourselves recursively for a directory */
! if (!rmtree(filepath, true))
! return false;
! }
! else
! {
! if (init_unlink(filepath) != 0)
! return false;
! }
! }
!
! if (rmtopdir)
! {
! if (rmdir(path) != 0)
! return false;
! }
!
! return true;
}
+ #ifdef WIN32
+
+ /* workaround for win32 unlink bug, not using logging like in
port/dirmod.c */
+
+ /* make sure we call the real unlink from MSVCRT */
+
+ #ifdef unlink
+ #undef unlink
+ #endif
+
+ static int
+ init_unlink(const char *path)
+ {
Re: [HACKERS] Minor DROP TABLESPACE issue
Tom Lane wrote: Although DROP TABLESPACE can detect tables existing in the target tablespace, it doesn't have any way to detect schemas that reference that tablespace as their default tablespace. Thus you can get implementation-level failures like this one: $ mkdir /tmp/junk regression=# create tablespace junk location '/tmp/junk'; CREATE TABLESPACE regression=# create schema junk tablespace junk; CREATE SCHEMA regression=# drop tablespace junk; DROP TABLESPACE Why this doesn't fail? The junk schema depend on tablespace junk, is there no dependencies between these two objects. G. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Minor DROP TABLESPACE issue
Gaetano Mendola [EMAIL PROTECTED] writes: is there no dependencies between these two objects. No, and there's little point in adding one, since it wouldn't prevent the problem from happening if you issue the DROP TABLESPACE from a different database. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Compile failure with SSL
I think this is another on of those 'might be Win32 specific' problems. When building on XP, with OpenSSL 0.9.7c (from the bitWalk MinGW tools), I get the following failure: gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -I./src/include/port/win32 -DEXEC_BACKEND -I../../../src/include/port/win32 -DBUILDING_DLL -c -o be-secure.o be-secure.c be-secure.c: In function `initialize_SSL': be-secure.c:653: `S_IRWXG' undeclared (first use in this function) be-secure.c:653: (Each undeclared identifier is reported only once be-secure.c:653: for each function it appears in.) be-secure.c:653: `S_IRWXO' undeclared (first use in this function) be-secure.c:654: warning: implicit declaration of function `getuid' make[3]: *** [be-secure.o] Error 1 make[3]: Leaving directory `/cvs/pgsql/src/backend/libpq' I have run 'make distclean' and './configure --with-openssl' to make sure everything is consistent. Any ideas? Regards, Dave ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Tablespace patch review
Andreas Pflug [EMAIL PROTECTED] writes: I could think of cases where temporary schemas should go to a different tablespace, but AFAICS since these are created implicitely there's no way to redirect them. Maybe an additional attribute in pg_database for a default temp tablespace is desirable? By default, temp tables will live in the database's default tablespace, which is not necessarily the pg_default tablespace. (Hmm, there's another good reason for renaming it ... if I'd said default tablespace I'd have had to go out of my way to make it clear what I meant.) This arguably is sufficient control. In any case, I'd prefer not to add a knob to relocate temp stuff until there's proven need for it. We can always add features later, but inventing stuff because somebody might need it is a recipe for overdesign. (Remember that you can always redirect a specific temp table to a specific tablespace when you create it.) The other thing I think people might possibly want to move around is pg_largeobject. If Gavin finishes ALTER TABLE SET TABLESPACE (or whatever we call it), that should provide a sufficient answer there. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Tablespace patch review
On Sat, 19 Jun 2004, Tom Lane wrote: [ switching to pghackers for wider comment ] Christopher Kings-Lynne [EMAIL PROTECTED] writes: By the way, I think that we should deny users the ability to create tablespaces that begin with pg_. Also, the existing ones should be pg_global and pg_default. That way, we have room to move if ever we decide we want more system tablespaces. It also makes it easier to dump non-system tablespaces. Seems like a reasonable suggestion to me. Any objections? BTW, another argument for this is that default is a reserved word. I'd already noticed in testing that CREATE TABLE ... TABLESPACE default doesn't work unless you double-quote default. Calling it pg_default would avoid that annoyance. Great idea. I recognised that default was reserved and was using default in testing. I meant to raise this for discussion when I submitted the patch. pg_default/pg_global are great. Gavin ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Cannot initdb in cvs tip
On Sun, 2004-06-20 at 08:04, Dave Page wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 19 June 2004 00:22
To: Dave Page
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Cannot initdb in cvs tip
Dave Page [EMAIL PROTECTED] writes:
I'm getting the following error when trying to initdb with CVS tip.
creating template1 database in
C:/msys/1.0/local/pgsql/data/base/1 ...
ERROR: could not open segment 1 of relation 1663/1/1255
(target block
26189776): No such file or directory
The target block number is obviously broken :-(. But maybe
you have a build consistency problem --- did you try a make
distclean and full rebuild?
OK, that cured that one - thanks.
although it says it's clearing the contents of the directory, in
actual fact it leaves the directory structure in place, thus a
subsequent initdb will not run without a manual clearup.
Hm. The rmtree() function in initdb.c is responsible for
this, and I see it has WIN32-specific behavior, which is
evidently wrong.
Can you recommend a fix?
The current solution does an rmdir /q /s $PGDATA if the datadir was
created, and del /q /s $PGDATA if the directory already existed. The
second case will not work, as del will not remove directories. AFAICS,
there is no easy way to do this using system() as rmdir won't accept
wildcards, so we can't do del $PGDATA/* rmdir $PGDATA/*.
It seems to me that the simple answer is to put Andrew's recursive
unlink code back in (as he suggested), which Bruce removed as rm etc.
were being used in commands/dbcommands.c (which should work fine under
Windows). Patch below
you could of course rmdir /s /q $PGDATA mkdir $PGDATA if the purpose
is to leave the directory intact if it already existed prior to install.
Regards,
John
Regards, Dave
*** initdb.c.orig Sat Jun 19 22:15:28 2004
--- initdb.c Sat Jun 19 23:02:10 2004
***
*** 132,137
--- 132,144
static void *xmalloc(size_t size);
static char *xstrdup(const char *s);
static bool rmtree(char *path, bool rmtopdir);
+
+ #ifdef WIN32
+ static int init_unlink(const char *);
+ #else
+ #define init_unlink(x) unlink( (x) )
+ #endif /* WIN32 */
+
static char **replace_token(char **lines, char *token, char
*replacement);
static char **readfile(char *path);
static void writefile(char *path, char **lines);
***
*** 245,264
static bool
rmtree(char *path, bool rmtopdir)
{
! charbuf[MAXPGPATH + 64];
! #ifndef WIN32
! /* doesn't handle .* files, but we don't make any... */
! snprintf(buf, sizeof(buf), rm -rf \%s\%s, path,
! rmtopdir ? : /*);
! #else
! snprintf(buf, sizeof(buf), %s /s /q \%s\,
! rmtopdir ? rmdir : del, path);
! #endif
! return !system(buf);
}
/*
* make a copy of the array of lines, with token replaced by
replacement
--- 252,349
static bool
rmtree(char *path, bool rmtopdir)
{
! charfilepath[MAXPGPATH];
! DIR*dir;
! struct dirent *file;
! char **filenames;
! char **filename;
! int numnames = 0;
! struct stat statbuf;
! /*
! * we copy all the names out of the directory before we start
modifying
! * it.
! *
! */
!
! dir = opendir(path);
! if (dir == NULL)
! return false;
! while ((file = readdir(dir)) != NULL)
! {
! if (strcmp(file-d_name, .) != 0
strcmp(file-d_name, ..) != 0)
! numnames++;
! }
!
! rewinddir(dir);
!
! filenames = xmalloc((numnames + 2) * sizeof(char *));
! numnames = 0;
!
! while ((file = readdir(dir)) != NULL)
! {
! if (strcmp(file-d_name, .) != 0
strcmp(file-d_name, ..) != 0)
! filenames[numnames++] = xstrdup(file-d_name);
! }
!
! filenames[numnames] = NULL;
!
! closedir(dir);
!
! /* now we have the names we can start removing things */
!
! for (filename = filenames; *filename; filename++)
! {
! snprintf(filepath, MAXPGPATH, %s/%s, path, *filename);
!
! if (stat(filepath, statbuf) != 0)
! return false;
!
! if (S_ISDIR(statbuf.st_mode))
! {
! /* call ourselves recursively for a directory */
! if (!rmtree(filepath, true))
! return false;
! }
! else
! {
! if (init_unlink(filepath) != 0)
! return false;
! }
! }
!
! if (rmtopdir)
! {
! if (rmdir(path) != 0)
! return false;
! }
!
! return true;
}
+ #ifdef
