I know installation questions are boring ...

* Alexander Jerusalem <ajeru@gmx.net> [001116 17:05] wrote:

... nevertheless I hav one :-)

I have installed postgresql 7.0 on NT. I've done all the necessary cygwin
and cygipc stuff but when I start up postres by entering

postgres -D ../data

I keep getting an intresting error message: "FATAL 1: Version number in
file '../data/PG_VERSION' should be 7.0, not 7.0"
Any ideas?

Don't use relative paths, use full paths.

--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."

Alexander Jerusalem <ajeru@gmx.net> writes:

I keep getting an intresting error message: "FATAL 1: Version number in
file '../data/PG_VERSION' should be 7.0, not 7.0"
Any ideas?

PG_VERSION should contain the 4 bytes "7.0\n". The initdb script
creates it in what may be too simplistic a fashion:

echo $version > "$PGDATA/PG_VERSION"

It sounds like your copy of echo decided to write the newline as
DOS-style \r\n instead of just \n.

Of course this just begs the question of why it works for some people
on NT and not others. Is this a difference across cygwin releases,
perhaps?

regards, tom lane

Thank you Alfred and Tom, I did both, use absolute paths and change
PG_VERSION to a UNIX format and it worked.

Unfortunately I'm running into another problem. Now when I try to start up
the postmaster by entering
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
I'm getting the error message: "FATAL 1: Database "ajeru" does not exist
in the system catalog."

ajeru is the username I'm logged in to. The initdb command was also
submitted under this user account so I believe ajeru must be the postgres
superuser. I don't understand this error message. Of course the database
doesn't exist. As I understand it I can only use createdb when the
postmaster is running.

Thank you for your patience,

Alexander Jerusalem
VKNN
ajeru@gmx.net

Unfortunately I'm running into another problem. Now when I try to start up
the postmaster by entering
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data

Shouldn't this be /usr/local/pgsql/bin/postmaster?
The postgres binary is the actual backend which AIUI won't do what
you want if you start it by hand.

John

--
John Gray
Senior Technician
BEANS INDUSTRY (UK) Ltd
3 Brindley Place
Birmingham B1 2JB
Tel +44-121-698-8672
Fax +44-121-698-8624
mailto:jgray@beansindustry.co.uk
http://www.beansindustry.co.uk

Tom Lane writes:

PG_VERSION should contain the 4 bytes "7.0\n". The initdb script
creates it in what may be too simplistic a fashion:

echo $version > "$PGDATA/PG_VERSION"

No, remember that this is new for 7.1. 7.0 uses

sprintf(version, "%s.%s\n", PG_RELEASE, PG_VERSION);
fd = open(full_path, O_WRONLY | O_CREAT | O_EXCL | O_BINARY, 0666);
write(fd, version, strlen(version));

which should not cause newline foul-ups.

Of course this just begs the question of why it works for some people
on NT and not others. Is this a difference across cygwin releases,
perhaps?

My understanding is that this is settable by mount-point, so the confusion
is practically unsurmountable.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

echo $version > "$PGDATA/PG_VERSION"

No, remember that this is new for 7.1. 7.0 uses

Oh, right, you rejiggered all that stuff a few months back. My mistake.

sprintf(version, "%s.%s\n", PG_RELEASE, PG_VERSION);
fd = open(full_path, O_WRONLY | O_CREAT | O_EXCL | O_BINARY, 0666);
write(fd, version, strlen(version));

which should not cause newline foul-ups.

Actually, the 7.0 code seems to apply O_BINARY only when __CYGWIN32__
is defined; I wonder if the NT version somehow got built without that?

Of course this just begs the question of why it works for some people
on NT and not others. Is this a difference across cygwin releases,
perhaps?

My understanding is that this is settable by mount-point, so the confusion
is practically unsurmountable.

But surely O_BINARY would prevent a newline translation from occurring
no matter what?

Or is it possible that Alexander tried to copy the files from one disk
to another, and the copy operation decided to do newline translations?

I still don't understand why he's seeing a failure...

regards, tom lane

I don't have a file called postmaster in my pgsql/bin directory so I
thought it must be postgres. And it looks like it is the right file, it
just doesn't work...

At 12:22 17.11.00, John Gray wrote:

At 18:03 17.11.00, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

I still don't understand why he's seeing a failure...

I'm not seeing this failure anymore after I have saved the file in a unix
format and using absolute paths. I don't know however which of the two
changes did the trick but I could try it if anybody is intrested in it.