Re: [HACKERS] Cannot initdb in cvs tip
Dave, now that we are nearing beta, I think we need to correct the
initdb problem with removing the directory on Win32. Would you code
this up as something that sits in /port/dirmod.c and have both initdb
and DROP DATABASE call the C routine rather than call rm -r/rmdir? (I
think those are the only two. DROP TABLESPACE?)
I wanted to keep a solution that was as native to the OS as possible,
but because we can't do that on Win32 and few people like the unix
system call to 'rm', it is time to clean it up.
One question --- why is there a sleep loop needed for unlink in your
patch?
---
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
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
Re: [HACKERS] Cannot initdb in cvs tip
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 28 July 2004 09:29 To: Dave Page Cc: Tom Lane; PostgreSQL-development; [EMAIL PROTECTED] Subject: Re: [HACKERS] Cannot initdb in cvs tip Dave, now that we are nearing beta, I think we need to correct the initdb problem with removing the directory on Win32. Would you code this up as something that sits in /port/dirmod.c and have both initdb and DROP DATABASE call the C routine rather than call rm -r/rmdir? (I think those are the only two. DROP TABLESPACE?) I'm pretty busy right now and can't guarantee I'll even be able to look at this until Friday (I spent the last 2 days on pg stuff so need to do some other things at work :-( ). If anyone has more time please shout, otherwise I'll get to this as soon as I can. I wanted to keep a solution that was as native to the OS as possible, but because we can't do that on Win32 and few people like the unix system call to 'rm', it is time to clean it up. Yup. One question --- why is there a sleep loop needed for unlink in your patch? I don't know - which leads me nicely onto point out that it's not my patch :-) I think it was Andrew that orginally wrote it - I just created the patch to put it back in after it was removed. Regards, Dave. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Cannot initdb in cvs tip
Dave Page wrote: -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 28 July 2004 09:29 To: Dave Page Cc: Tom Lane; PostgreSQL-development; [EMAIL PROTECTED] Subject: Re: [HACKERS] Cannot initdb in cvs tip Dave, now that we are nearing beta, I think we need to correct the initdb problem with removing the directory on Win32. Would you code this up as something that sits in /port/dirmod.c and have both initdb and DROP DATABASE call the C routine rather than call rm -r/rmdir? (I think those are the only two. DROP TABLESPACE?) I'm pretty busy right now and can't guarantee I'll even be able to look at this until Friday (I spent the last 2 days on pg stuff so need to do some other things at work :-( ). If anyone has more time please shout, otherwise I'll get to this as soon as I can. I wanted to keep a solution that was as native to the OS as possible, but because we can't do that on Win32 and few people like the unix system call to 'rm', it is time to clean it up. Yup. One question --- why is there a sleep loop needed for unlink in your patch? I don't know - which leads me nicely onto point out that it's not my patch :-) I think it was Andrew that orginally wrote it - I just created the patch to put it back in after it was removed. I will try to get a patch out today. IIRC, the Sleep came from the code I stole from somewhere else - but I will revisit the whole thing. 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] Cannot initdb in cvs tip
Bruce Momjian wrote: Dave, now that we are nearing beta, I think we need to correct the initdb problem with removing the directory on Win32. Would you code this up as something that sits in /port/dirmod.c and have both initdb and DROP DATABASE call the C routine rather than call rm -r/rmdir? (I think those are the only two. DROP TABLESPACE?) The small wrinkle here is that rmtree needs to make a copy of the file names before it starts removing things. In the backend case that means calling palloc() and friends - am I correct in assuming it is reasonable to do this in whatever context happens to be current when rmtree is called? (I promise to make it clean up nicely). I wanted to keep a solution that was as native to the OS as possible, but because we can't do that on Win32 and few people like the unix system call to 'rm', it is time to clean it up. One question --- why is there a sleep loop needed for unlink in your patch? We will just be calling the existing pgunlink() (which has a sleep) in the Windows cases, so this question becomes moot. 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] Cannot initdb in cvs tip
Andrew Dunstan [EMAIL PROTECTED] writes: The small wrinkle here is that rmtree needs to make a copy of the file names before it starts removing things. In the backend case that means calling palloc() and friends - am I correct in assuming it is reasonable to do this in whatever context happens to be current when rmtree is called? Sure. regards, tom lane ---(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] Cannot initdb in cvs tip
Andrew Dunstan wrote: I wanted to keep a solution that was as native to the OS as possible, but because we can't do that on Win32 and few people like the unix system call to 'rm', it is time to clean it up. One question --- why is there a sleep loop needed for unlink in your patch? We will just be calling the existing pgunlink() (which has a sleep) in the Windows cases, so this question becomes moot. Great. Thanks. Sorry I delayed addressing this for so long. Should we look at replacing cp/copy in 7.6? -- 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] Cannot initdb in cvs tip
Seems it might be time to address this and get it fixed. Win32 doesn't clean up the directory structure under /data and leave /data unchanged, and there is no way to do this with a system() command on Win32. I resisted adding a C version of rmtree during Win32 development because I was concerned about disturbing the Unix behavior, but at this point I think we should just move ahead and add a /port function for this and remove the system() backend and initdb calls to 'rm' for directories. --- Andrew Dunstan wrote: John Hansen said: On Sun, 2004-06-20 at 08:04, Dave Page wrote: 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. No we can't. This was discussed months ago, IIRC. The user might very well not have the privileges necessary to delete the directory, and might not have the privileges to recreate it if they do. The direct recursive delete is not a lot of code, and I must confess I *hate* having C programs calling system() for such tasks. One of my goals in rewriting initdb in C was to avoid any calls at all to any external program other than postgres itself. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Cannot initdb in cvs tip
John Hansen said: On Sun, 2004-06-20 at 08:04, Dave Page wrote: 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. No we can't. This was discussed months ago, IIRC. The user might very well not have the privileges necessary to delete the directory, and might not have the privileges to recreate it if they do. The direct recursive delete is not a lot of code, and I must confess I *hate* having C programs calling system() for such tasks. One of my goals in rewriting initdb in C was to avoid any calls at all to any external program other than postgres itself. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Cannot initdb in cvs tip
-Original Message- From: John Hansen [mailto:[EMAIL PROTECTED] Sent: Sun 6/20/2004 2:27 AM To: Dave Page Cc: Tom Lane; PostgreSQL-development; [EMAIL PROTECTED] Subject: Re: [HACKERS] Cannot initdb in cvs tip 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. Permissions may not allow you to do that. Regards, Dave ---(end of broadcast)--- TIP 8: explain analyze is your friend
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] 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] 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
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? 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? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Cannot initdb in cvs tip
Tom Lane said: 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? 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? You can use the builtin one I wrote originally (and tested quite a bit) that doesn't depend on system() calls ;-) cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
