?
---
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
-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
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
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
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
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?
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
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
-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
-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
-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
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
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
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
14 matches
Mail list logo