I just noticed that if I don't specify a data directory either on the
command line or in $PGDATA,, pg_ctl fails silently on Windows (haven't
been able to test other platforms atm). Is this a bug or an oversight -
an error message would seem appropriate?

/D

postgres@PC30:/usr/local/pgsql$ bin/pg_ctl start
postgres@PC30:/usr/local/pgsql$ bin/pg_ctl -D data start
postmaster starting
postgres@PC30:/usr/local/pgsql$ LOG: database system was interrupted at
2005-08-29 00:34:07 GMT Standard Time
LOG: checkpoint record is at 0/39F218
LOG: redo record is at 0/39F218; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 1478; next OID: 16392
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: database system was not properly shut down; automatic recovery in
progress
LOG: record with zero length at 0/39F260
LOG: redo is not required
LOG: database system is ready
LOG: transaction ID wrap limit is 2147484144, limited by database
"postgres"

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

"Dave Page" <dpage (AT) vale-housing (DOT) co.uk> writes:
On my machine it does this:

$ bin/pg_ctl start
pg_ctl: no database directory specified and environment variable PGDATA unset
Try "pg_ctl --help" for more information.
$

Is write_stderr() broken on Windows?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

In some cases it writes to the eventlog instead of stderr. Dave, can you
check if this is what's happening to you?

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

"Dave Page" <dpage (AT) vale-housing (DOT) co.uk> writes:
pg_ctl doesn't read the config file, though. Probably we need to
make write_stderr aware that it's running in an interactive program
rather than in the postmaster, and never use the eventlog in this context.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

=20

Bah, no coffee for 2 weeks dulls the mind :-(

Yes, this is what's happening. Odd though, considering that I have:

#log_destination =3D 'stderr'

In my out-of-the-box config.

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

This is output from pg_ctl, right? pg_ctl doesn't look at
postgresql.conf...

pg_ctl has:
if (!isatty(fileno(stderr))) /* Running as a service */
.... write to eventlog ...


That check appears to be failing. The backend has a lot more elaborate
check (in port/backend/security.c). Perhaps we need to make that kind of
advanced check in pg_ctl as well?

Though I don't see any of this code changing lately, so I don't see why
it's failing now. Are you running it under some kind of different
environment than you used to? Any other ideas on why it would claim your
console is not a tty?

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

It must sitll use the eventlog when called as a service control process,
otherwise any error output from pg_ctl in that scenario would go to
/dev/null...=20
There is code that attempts to check this, but it's apparantly failing.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

=20

Which makes sense given that the entire problem is that it doesn't know
where to find the config file!

/D

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

"Magnus Hagander" <mha (AT) sollentuna (DOT) net> writes:
Well, are we sure that it was working for Dave before? Maybe it's a
long-standing problem. If you didn't happen to mistype a command you'd
not know it wasn't working.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

=20

The only change is a new install of msys a month or so back, so nothing
major ;-). I can't think of anything that /should/ have changed that
behaviour.

Regards, Dave

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend