UPDATE 2: Windows XP, Cygwin 1.3.22-1, PostgreSQL 7.3.2, CygIPC 1.13.2-1 installation steps

[2nd posting, as 1st never reached list due to non-membership. Now a
member, so hoping it will post quickly. Apologies in advance for
duplication if 1st post ever makes it.]

NOTE: This is a long message, however most are screen copy/pastes which
can be skimmed over. I have taken great pains to document the steps
clearly, so as to prevent confusion. If I have left out anything,
please advise. Unless otherwise noted, commands are done running as a
user who is a member of the NT Administrators group. (I have removed
1st line of BASH shell prompt for easier reading.)

For the past few weeks, I have been trying to get PostgreSQL 7.3.2
installed as an NT service using the usual methods. Please note I have
done this in the past, under Windows 2000, using various versions of
PostgreSQL (7.1 and 7.2.1 come to mind), so I am familiar with the
steps. Unfortunately, now I am running into difficulty, and after
having read this newsgroup, as well the usual Google searches, I have
come to the gut conclusion that the latest release revs of Cygwin appear
to have some kind of permission issue, possibly related to what I've
read about 'ntsec' being turned on by default in recent versions.
Unfortunately, I cannot track down the culprit. So I am asking for any
and all help in determining what various file/directory permissions need
to be.

Please note this problem has occurred on multiple PCs now, both running
Windows 2000 and Windows XP Pro. The following was my last attempt,
documented step-for-step, so you can see what I have done.

HARDWARE:
Windows XP Professional SP1
with all updates thru today (29Apr2003)
Intel PIII 866MHz CPU
512MB SDRAM
20GB HD (approx. 5GB free) / one NTFS partition (C:)

* Completely removed Cygwin from PC:
* Removed C:\cygwin directory tree
* Removed 'HKLM\Software\Cygnus Solutions' Registry key
* Removed 'HKCU\Software\Cygnus Solutions' Registry key
* Removed CYGWIN environment variable (and rebooted)
* Left NT user 'postgres' (member of 'Users' group only)
* Left Local Security Policy setting that allowed
NT user 'postgres' to 'Log on as a service'
* Left PATH environment variable listing 'C:\cygwin\bin'
Beginning of PATH looks as follows:
"C:\Perl\bin\;C:\WINDOWS\system32;C:\WINDOWS;C:\Cygwin\bin;..."

NOTE: ActiveState ActivePerl v5.8.0.806 is located in
c:\Perl, in case it matters.

I have a local server mirroring a Cygwin mirror site (RCN), so my
install is done via a Windows share that is mapped to a drive letter
(i.e., install from local directory).

CYGWIN VERSION INFO:
Cygwin setup.exe v2.340.2.5
Cygwin v1.3.22-1
CygIPC v1.13.2-1
PostgreSQL v7.3.2 (as packaged in Cygwin distribution)

* Logged in as user with Administrative Rights.
* Ran cygwin setup.exe, disabled virus scanner (McAfee), installed from
local directory, and did a FULL install (EVERYTHING) vs. the default.
Didn't want issues of missing packages, etc., and I've got the HD
space.

* Once installed, ran BASH shell and did following (to show
permissions):
______________________________________________________________________
$ ls -al
total 2
drwxrwx---+ 10 Frank Users 0 Apr 29 11:06 .
drwxrwx---+ 10 Frank Users 0 Apr 29 11:06 ..
drwxrwx---+ 3 Frank Users 0 Apr 29 11:05 bin
-rwxr-x---+ 1 Frank Users 57 Apr 29 11:02 cygwin.bat
-rwxr-x---+ 1 Frank Users 766 Apr 29 11:02 cygwin.ico
drwxrwx---+ 19 Frank Users 0 Apr 29 11:05 etc
drwxrwxrwx+ 3 Frank None 0 Apr 29 11:06 home
drwxrwx---+ 27 Frank Users 0 Apr 29 11:05 lib
drwxrwx---+ 2 Frank Users 0 Apr 29 10:51 sbin
drwxrwx---+ 3 Frank Users 0 Apr 29 11:07 tmp
drwxrwx---+ 23 Frank Users 0 Apr 29 11:03 usr
drwxrwx---+ 9 Frank Users 0 Apr 29 11:03 var
______________________________________________________________________

* As indicated in various posts, /tmp should be writable by all, so
did

$ chmod 777 /tmp

* Then, to verify, did...
______________________________________________________________________
$ ls -al
total 2
drwxrwx---+ 10 Frank Users 0 Apr 29 11:06 .
drwxrwx---+ 10 Frank Users 0 Apr 29 11:06 ..
drwxrwx---+ 3 Frank Users 0 Apr 29 11:05 bin
-rwxr-x---+ 1 Frank Users 57 Apr 29 11:02 cygwin.bat
-rwxr-x---+ 1 Frank Users 766 Apr 29 11:02 cygwin.ico
drwxrwx---+ 19 Frank Users 0 Apr 29 11:05 etc
drwxrwxrwx+ 3 Frank None 0 Apr 29 11:06 home
drwxrwx---+ 27 Frank Users 0 Apr 29 11:05 lib
drwxrwx---+ 2 Frank Users 0 Apr 29 10:51 sbin
drwxrwxrwx+ 2 Frank Users 0 Apr 29 11:38 tmp
drwxrwx---+ 23 Frank Users 0 Apr 29 11:03 usr
drwxrwx---+ 9 Frank Users 0 Apr 29 11:03 var
______________________________________________________________________

* Using Windows Explorer, copied over cygipc-1.13-2.tar.bz2 into /tmp
by dropping file in C:\cygwin\tmp.

* As documented on cygipc site at
http://www.neuro.gatech.edu/users/cwilson/cygutils/how_to_install.html

Entered the following commands to install cygipc:
______________________________________________________________________
$ cd /
$ bunzip2 -c /tmp/CygIPC/v1.13-2/cygipc-1.13-2.tar.bz2 | tar xvf -
usr/
usr/local/
usr/local/bin/
usr/local/bin/ipc-daemon.exe
usr/local/bin/ipck
usr/local/bin/ipcrm.exe
usr/local/bin/ipcs.exe
usr/local/bin/ipctest.exe
usr/local/doc/
usr/local/doc/cygipc-1.13/
usr/local/doc/cygipc-1.13/ChangeLog
usr/local/doc/cygipc-1.13/contents_motif.gif
usr/local/doc/cygipc-1.13/COPYING
usr/local/doc/cygipc-1.13/index.html
usr/local/doc/cygipc-1.13/NEWS
usr/local/doc/cygipc-1.13/next_motif.gif
usr/local/doc/cygipc-1.13/node21.html
...[clip]...
usr/local/doc/cygipc-1.13/node81.html
usr/local/doc/cygipc-1.13/previous_motif.gif
usr/local/doc/cygipc-1.13/README
usr/local/doc/cygipc-1.13/README.old
usr/local/doc/cygipc-1.13/TODO
usr/local/doc/cygipc-1.13/up_motif.gif
usr/local/doc/cygipc-1.13/USAGE
usr/local/doc/Cygwin/
usr/local/include/
usr/local/include/sys/
usr/local/include/sys/ipc.h
usr/local/include/sys/ipctrace.h
usr/local/include/sys/msg.h
usr/local/include/sys/sem.h
usr/local/include/sys/shm.h
usr/local/lib/
usr/local/lib/libcygipc.a
______________________________________________________________________

* Using the document: /usr/doc/cygwin/postgresql-7.3.2.README

Followed the steps for NT service as indicated under section headed
with "The following is the NT services Cygwin PostgreSQL
installation procedure"

1. $ ipc-daemon --install-as-service
[Copy/pasted...worked fine]

NOTE: Double-checked, and NT service "Cygwin IPC Daemon" is set
to 'Automatic' and will Log On As 'Local System'.

2. NT user 'postgres' already existed prior to Cygwin install, so I
assume this was not necessary. Looking in /etc/passwd, I see the
account listed.

NOTE: Interesting observation. I notice if you do a
'mkpasswd -g' and just look at the output on the screen,
the format shown does NOT match what is in the /etc/group
file. Specifically, the GUID indicated by mkpasswd is
what you'd expect in Unix, but the /etc/group file shows
NT SUID-RIDs. I ran into this when I tried making changes
at one point (prior to ripping Cygwin completely off box,
so should not affect this here), and the result was that
directory listings showed goofed up group settings.
Not sure if this plays into the new default behavior of
'ntsec' being turned on.

3. Already done, but to make sure, I removed and re-added user 'postgres'.

4. $ cygrunsrv --install postmaster --path /usr/bin/postmaster --args
"-D /usr/share/postgresql/data -i" --dep ipc-daemon --termsig INT --user
postgres --shutdown
[Copy/pasted from instructions into BASH shell, and worked fine.]

NOTE: Double-checked, and NT service 'postmaster' is set to
'Automatic' and will Log On As '.\postgres'

5. $ mkdir /usr/share/postgresql/data
[Copy/pasted...worked fine.]

6. $ chown postgres /usr/share/postgresql/data
[Copy/pasted...worked fine.]

7. [Copy/pasted...worked fine...got the following:]
__________________________________________________________________

$ net start ipc-daemon
The Cygwin IPC Daemon service is starting.
The Cygwin IPC Daemon service was started successfully.
__________________________________________________________________

8. [To do this step, I closed the BASH shell (to be safe), did a
Log Off/Switch User, logged in as user 'postgres', ran the
commands, and copy/pasted the following to a file:
___________________________________________________________________
postgres(at)SEESINK ~
$ initdb -D /usr/share/postgresql/data
The files belonging to this database system will be owned by user
"postgres".
This user must also own the server process.

The database cluster will be initialized with locale C.

Fixing permissions on existing directory /usr/share/postgresql/data... ok
creating directory /usr/share/postgresql/data/base... ok
creating directory /usr/share/postgresql/data/global... ok
creating directory /usr/share/postgresql/data/pg_xlog... ok
creating directory /usr/share/postgresql/data/pg_clog... ok
creating template1 database in /usr/share/postgresql/data/base/1...
IpcSemaphore
Create: semget(key=1, num=17, 03600) failed: Function not implemented

initdb failed.
______________________________________________________________________

* Logging off from user 'postgres' and logging back in as administrator,
I performed the following:
______________________________________________________________________
$ cd /usr/share/postgresql
$ ls -al
total 317
drwxrwx---+ 5 Frank Users 0 Apr 29 12:07 .
drwxrwx---+ 43 Frank Users 0 Apr 29 11:02 ..
drwxrwx---+ 2 Frank Users 0 Apr 29 10:50 contrib
-rwxr-x---+ 1 Frank Users 38176 Feb 18 11:14
conversion_create.sql
drwx------+ 2 postgres None 0 Apr 29 12:15 data
drwxrwx---+ 2 Frank Users 0 Apr 29 10:50 java
-rwxr-x---+ 1 Frank Users 2329 Feb 18 11:14 pg_hba.conf.sample
-rwxr-x---+ 1 Frank Users 1441 Feb 18 11:14 pg_ident.conf.sample
-rwxr-x---+ 1 Frank Users 225491 Feb 18 11:14 postgres.bki
-rwxr-x---+ 1 Frank Users 48627 Feb 18 11:14 postgres.description
-rwxr-x---+ 1 Frank Users 5043 Feb 18 11:14
postgresql.conf.sample
______________________________________________________________________

* In order to delete the /usr/share/postgresql/data folder, I need to
reset the owner (as the permissions are for user 'postgres' ONLY.
Once deleted, I recreate the directory again to make another attempt.
______________________________________________________________________
$ chown -R Frank:Users data
$ cd data
$ ls -al
total 1
drwx------+ 6 Frank Users 0 Apr 29 12:15 .
drwxrwx---+ 5 Frank Users 0 Apr 29 12:07 ..
-rw------- 1 Frank Users 4 Apr 29 12:15 PG_VERSION
drwx------+ 3 Frank Users 0 Apr 29 12:15 base
drwx------+ 2 Frank Users 0 Apr 29 12:15 global
drwx------+ 2 Frank Users 0 Apr 29 12:15 pg_clog
drwx------+ 2 Frank Users 0 Apr 29 12:15 pg_xlog

$ rm -rf *
$ cd ..
$ rmdir data
$ cd
$ mkdir /usr/share/postgresql/data
______________________________________________________________________

* This time, I'll stay logged in as the administrator, making NO
changes whatsoever, to demonstrate that the problem appears to be
permissions-related (as this will succeed as shown):
______________________________________________________________________
$ initdb -D /usr/share/postgresql/data
The files belonging to this database system will be owned by user "Frank".
This user must also own the server process.

The database cluster will be initialized with locale C.

Fixing permissions on existing directory /usr/share/postgresql/data... ok
creating directory /usr/share/postgresql/data/base... ok
creating directory /usr/share/postgresql/data/global... ok
creating directory /usr/share/postgresql/data/pg_xlog... ok
creating directory /usr/share/postgresql/data/pg_clog... ok
creating template1 database in /usr/share/postgresql/data/base/1... ok
creating configuration files... ok
initializing pg_shadow... ok
enabling unlimited row size for system tables... ok
initializing pg_depend... ok
creating system views... ok
loading pg_description... ok
creating conversions... ok
setting privileges on built-in objects... ok
vacuuming database template1... ok
copying template1 to template0... ok

Success. You can now start the database server using:

/usr/bin/postmaster -D /usr/share/postgresql/data
or
/usr/bin/pg_ctl -D /usr/share/postgresql/data -l logfile start
______________________________________________________________________

* TADA! As the NT Administrator used to install Cygwin, this works.

* Having read in various posts that permissions appear to be mangled,
not only with /tmp, but also with /usr/bin, I decided to take a
look (only showing portion, but rest looks the same):
______________________________________________________________________
$ cd /usr/bin
$ ls -al
...
-rwxr-x---+ 1 Frank Users 1981952 Feb 18 11:15 postgres.exe
lrwxrwxrwx 1 Frank Users 23 Apr 29 10:50 postmaster ->
postgres.e
xe
-rwxr-x---+ 1 Frank Users 16896 Feb 24 00:04 ppm2tiff.exe
-rwxr-x---+ 1 Frank Users 66560 Feb 18 11:15 pq.dll
-rwxr-x---+ 1 Frank Users 32768 Feb 19 2002 pr.exe
-rwxr-x---+ 1 Frank Users 90112 Dec 16 13:03 pre-grohtml.exe
-rwxr-x---+ 1 Frank Users 206 Oct 26 2002 printafm
-rwxr-x---+ 1 Frank Users 23040 Jan 7 00:49 printenv.exe
-rwxr-x---+ 1 Frank Users 30720 Jan 7 00:49 printf.exe
-rwxr-x---+ 1 Frank Users 39592 Sep 20 2002 prockill.exe
-rwxr-x---+ 1 Frank Users 61952 Aug 19 2002 procmail.exe
-rwxr-x---+ 1 Frank Users 74752 Sep 20 2002 procps.exe
-rwxr-x---+ 1 Frank Users 19456 Mar 18 09:21 ps.exe
-rwxr-x---+ 1 Frank Users 640 Oct 26 2002 ps2ascii
-rwxr-x---+ 1 Frank Users 1740 Oct 26 2002 ps2epsi
-rwxr-x---+ 1 Frank Users 229 Mar 5 15:13 ps2frag
-rwxr-x---+ 1 Frank Users 211 Oct 26 2002 ps2pdf
-rwxr-x---+ 1 Frank Users 173 Oct 26 2002 ps2pdf12
-rwxr-x---+ 1 Frank Users 173 Oct 26 2002 ps2pdf13
-rwxr-x---+ 1 Frank Users 173 Oct 26 2002 ps2pdf14
-rwxr-x---+ 1 Frank Users 899 Oct 26 2002 ps2pdfwr
-rwxr-x---+ 1 Frank Users 105472 Mar 5 15:13 ps2pk.exe
-rwxr-x---+ 1 Frank Users 373 Oct 26 2002 ps2ps
-rwxr-x---+ 1 Frank Users 52697 Mar 30 12:18 psed
-rwxr-x---+ 1 Frank Users 980 Mar 5 15:13 pslatex
-rwxr-x---+ 1 Frank Users 140288 Feb 18 11:15 psql.exe
...
______________________________________________________________________

* As seen above, /usr/bin/ is set so only the owner and group have
execute permission. As Jason Tishler has noted several times, one
possibility is setting execute permissions for all. So I did this:
______________________________________________________________________
$ chmod a+rx /usr/bin /usr/bin/*
chmod: changing permissions of `/usr/bin/amstex': No such file or directory
chmod: changing permissions of `/usr/bin/csh': No such file or directory
chmod: changing permissions of `/usr/bin/egrep': No such file or directory
chmod: changing permissions of `/usr/bin/elatex': No such file or directory
chmod: changing permissions of `/usr/bin/fgrep': No such file or directory
chmod: changing permissions of `/usr/bin/jadetex': No such file or directory
chmod: changing permissions of `/usr/bin/lambda': No such file or directory
chmod: changing permissions of `/usr/bin/mcedit': No such file or directory
chmod: changing permissions of `/usr/bin/mcview': No such file or directory
chmod: changing permissions of `/usr/bin/pdfelatex': No such file or
directory
chmod: changing permissions of `/usr/bin/pdfjadetex': No such file or
directory
chmod: changing permissions of `/usr/bin/pdflatex': No such file or
directory
chmod: getting attributes of `/usr/bin/pidof': No such file or directory
chmod: changing permissions of `/usr/bin/virmf': No such file or directory
______________________________________________________________________

* Checking /usr/bin again:
______________________________________________________________________
$ cd /usr/bin
$ ls -al
...
-rwxr-xr-x+ 1 Frank Users 1981952 Feb 18 11:15 postgres.exe
lrwxrwxrwx 1 Frank Users 23 Apr 29 10:50 postmaster ->
postgres.e
xe
-rwxr-xr-x+ 1 Frank Users 16896 Feb 24 00:04 ppm2tiff.exe
-rwxr-xr-x+ 1 Frank Users 66560 Feb 18 11:15 pq.dll
-rwxr-xr-x+ 1 Frank Users 32768 Feb 19 2002 pr.exe
-rwxr-xr-x+ 1 Frank Users 90112 Dec 16 13:03 pre-grohtml.exe
-rwxr-xr-x+ 1 Frank Users 206 Oct 26 2002 printafm
-rwxr-xr-x+ 1 Frank Users 23040 Jan 7 00:49 printenv.exe
-rwxr-xr-x+ 1 Frank Users 30720 Jan 7 00:49 printf.exe
-rwxr-xr-x+ 1 Frank Users 39592 Sep 20 2002 prockill.exe
-rwxr-xr-x+ 1 Frank Users 61952 Aug 19 2002 procmail.exe
-rwxr-xr-x+ 1 Frank Users 74752 Sep 20 2002 procps.exe
-rwxr-xr-x+ 1 Frank Users 19456 Mar 18 09:21 ps.exe
-rwxr-xr-x+ 1 Frank Users 640 Oct 26 2002 ps2ascii
-rwxr-xr-x+ 1 Frank Users 1740 Oct 26 2002 ps2epsi
-rwxr-xr-x+ 1 Frank Users 229 Mar 5 15:13 ps2frag
-rwxr-xr-x+ 1 Frank Users 211 Oct 26 2002 ps2pdf
-rwxr-xr-x+ 1 Frank Users 173 Oct 26 2002 ps2pdf12
-rwxr-xr-x+ 1 Frank Users 173 Oct 26 2002 ps2pdf13
-rwxr-xr-x+ 1 Frank Users 173 Oct 26 2002 ps2pdf14
-rwxr-xr-x+ 1 Frank Users 899 Oct 26 2002 ps2pdfwr
-rwxr-xr-x+ 1 Frank Users 105472 Mar 5 15:13 ps2pk.exe
-rwxr-xr-x+ 1 Frank Users 373 Oct 26 2002 ps2ps
-rwxr-xr-x+ 1 Frank Users 52697 Mar 30 12:18 psed
-rwxr-xr-x+ 1 Frank Users 980 Mar 5 15:13 pslatex
-rwxr-xr-x+ 1 Frank Users 140288 Feb 18 11:15 psql.exe
...
______________________________________________________________________

* Next up, let's look at /tmp from the admin account's point of view:
______________________________________________________________________
$ cd /tmp
$ ls -al
total 4046
drwxrwxrwx+ 3 Frank Users 0 Apr 29 12:09 .
drwxrwx---+ 10 Frank Users 0 Apr 29 11:06 ..
drwxrwxrwx+ 3 Frank None 0 Apr 29 11:40 CygIPC
-rw-rw-rw- 1 SYSTEM Administ 3916520 Apr 29 12:09 MultiFileMsg
-rw-rw-rw- 1 SYSTEM Administ 22032 Apr 29 12:09 MultiFileSem
-rw-rw-rw- 1 SYSTEM Administ 202768 Apr 29 12:09 MultiFileShm
______________________________________________________________________

* Since I did a chmod on /tmp, the CygIPC files (Multi*) show read/write
permissions for all. That's good.

* So, with /usr/bin permissions adjusted, let's try again. And to be
sure, let's also change group ownership:
______________________________________________________________________
$ mkdir /usr/share/postgresql/data
$ chown postgres:Users /usr/share/postgresql/data
$ ls -al /usr/share/postgresql/
total 317
drwxrwx---+ 5 Frank Users 0 Apr 29 12:26 .
drwxrwx---+ 43 Frank Users 0 Apr 29 11:02 ..
drwxrwx---+ 2 Frank Users 0 Apr 29 10:50 contrib
-rwxr-x---+ 1 Frank Users 38176 Feb 18 11:14
conversion_create.sql
drwxr-xr-x+ 2 postgres Users 0 Apr 29 12:26 data
drwxrwx---+ 2 Frank Users 0 Apr 29 10:50 java
-rwxr-x---+ 1 Frank Users 2329 Feb 18 11:14 pg_hba.conf.sample
-rwxr-x---+ 1 Frank Users 1441 Feb 18 11:14 pg_ident.conf.sample
-rwxr-x---+ 1 Frank Users 225491 Feb 18 11:14 postgres.bki
-rwxr-x---+ 1 Frank Users 48627 Feb 18 11:14 postgres.description
-rwxr-x---+ 1 Frank Users 5043 Feb 18 11:14
postgresql.conf.sample
______________________________________________________________________

* Next let's stop cygipc, delete the tmp files, then restart, just to
make sure:
______________________________________________________________________
$ net stop ipc-daemon
The Cygwin IPC Daemon service is stopping.
The Cygwin IPC Daemon service was stopped successfully.

$ rm /tmp/MultiFile*
$ net start ipc-daemon
The Cygwin IPC Daemon service is starting.
The Cygwin IPC Daemon service was started successfully.
______________________________________________________________________

* Finally, let's switch back to 'postgres' account, look at the cygipc
tmp files (just to see what permissions we see from 'postgres' acct,
and then let's try again:
______________________________________________________________________
postgres(at)SEESINK ~
$ ls -al /tmp
total 4046
drwxrwxrwx+ 3 Frank Users 0 Apr 29 12:28 .
drwxrwx---+ 10 Frank Users 0 Apr 29 11:06 ..
drwxrwxrwx+ 3 Frank None 0 Apr 29 11:40 CygIPC
-rw-rw-rw- 1 SYSTEM Administ 3916520 Apr 29 12:28 MultiFileMsg
-rw-rw-rw- 1 SYSTEM Administ 22032 Apr 29 12:28 MultiFileSem
-rw-rw-rw- 1 SYSTEM Administ 202768 Apr 29 12:28 MultiFileShm

$ initdb -D /usr/share/postgresql/data
The files belonging to this database system will be owned by user
"postgres".
This user must also own the server process.

The database cluster will be initialized with locale C.

Fixing permissions on existing directory /usr/share/postgresql/data... ok
creating directory /usr/share/postgresql/data/base... ok
creating directory /usr/share/postgresql/data/global... ok
creating directory /usr/share/postgresql/data/pg_xlog... ok
creating directory /usr/share/postgresql/data/pg_clog... ok
creating template1 database in /usr/share/postgresql/data/base/1...
IpcSemaphore
Create: semget(key=1, num=17, 03600) failed: Function not implemented

initdb failed.
______________________________________________________________________

* BZZZZ! Still not happening. Just for a quick look, here's what we
see in /usr/share/postgresql:
______________________________________________________________________
postgres(at)SEESINK /usr/share/postgresql/data
$ ls -al
total 1
drwx------+ 6 postgres Users 0 Apr 29 12:30 .
drwxrwx---+ 5 Frank Users 0 Apr 29 12:26 ..
-rw------- 1 postgres None 4 Apr 29 12:30 PG_VERSION
drwx------+ 3 postgres None 0 Apr 29 12:30 base
drwx------+ 2 postgres None 0 Apr 29 12:30 global
drwx------+ 2 postgres None 0 Apr 29 12:30 pg_clog
drwx------+ 2 postgres None 0 Apr 29 12:30 pg_xlog
______________________________________________________________________

FINAL COMMENTS:

The issue definitely appears to be permissions-related, as I was easily
able to execute 'initdb' from the NT administrator account. But what am
I missing?

Please note I have also tried changing the 'Cygwin IPC Daemon' service
permissions to make the service run in the same 'postgres' user context
if that were the case (doing the usual deleting of the /tmp/Multi* files
of course prior to launching), but to no avail. Doing so showed the
/tmp/Multi* files as follows:
______________________________________________________________________
$ cd /tmp
$ ls -al
total 4046
drwxrwxrwx+ 3 Frank Users 0 Apr 29 13:36 .
drwxrwx---+ 10 Frank Users 0 Apr 29 11:06 ..
drwxrwxrwx+ 3 Frank None 0 Apr 29 11:40 CygIPC
-rw-rw-rw- 1 postgres None 3916520 Apr 29 13:36 MultiFileMsg
-rw-rw-rw- 1 postgres None 22032 Apr 29 13:36 MultiFileSem
-rw-rw-rw- 1 postgres None 202768 Apr 29 13:36 MultiFileShm
______________________________________________________________________

And no matter what, the following test was always the same when run from
the 'postgres' user account:
______________________________________________________________________
$ ipctest s
Test v0.03
Unable to create semaphore
semget : Function not implemented
______________________________________________________________________

If this isn't detailed enough, please let me know what other information
might be of use.

Thanks in advance for any and all help in this regard. I've been
scratching my head on this one for awhile. I have searched all over
looking for answers before posting here, but if I've overlooked
something trivial...well, apologies in advance.

Frank,

On Wed, Apr 30, 2003 at 12:55:40PM -0400, Frank Seesink wrote:
> And no matter what, the following test was always the same when run
> from the 'postgres' user account:
> ______________________________________________________________________
> $ ipctest s
> Test v0.03
> Unable to create semaphore
> semget : Function not implemented
> ______________________________________________________________________

The above is the crux of your problem. Until you get the above to work,
PostgreSQL is sure to fail. Sorry, but my only suggestion will require
some effort. I recommend building a (debug-able) version of cygipc with
tracing enabled. You may be able to determine what the problem is from
the trace output. Otherwise, there is always gdb...

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Jason Tishler wrote:
> Frank,
>
> On Wed, Apr 30, 2003 at 12:55:40PM -0400, Frank Seesink wrote:
>
>>And no matter what, the following test was always the same when run
>>from the 'postgres' user account:
>>______________________________________________________________________
>>$ ipctest s
>>Test v0.03
>>Unable to create semaphore
>>semget : Function not implemented
>>______________________________________________________________________
>
>
> The above is the crux of your problem. Until you get the above to work,
> PostgreSQL is sure to fail. Sorry, but my only suggestion will require
> some effort. I recommend building a (debug-able) version of cygipc with
> tracing enabled. You may be able to determine what the problem is from
> the trace output. Otherwise, there is always gdb...

Oh, you're kidding, right? Please tell me you're kidding. Man, what
has happened since the last time I did a Cygwin PostgreSQL install? It
used to be so smooth...once you followed the instructions of
course...which, by the way, thanks, Jason, for clearing up the starting
of CygIPC before doing an initdb...the older versions of the doc were
missing that step, and it took me awhile to figure it out when I was
first starting with PostgreSQL under Cygwin.

Am I truly unique in this situation, or are other people experiencing
the same difficulty? From what I gather, I'm not alone. And I haven't
found any definitve solution out there; only indications that CygIPC has
bugs, and the developer is AWOL (or so you made it sound in another post
I read).

Is the answer to backpedal to an older version of PostgreSQL (and
possibly CygIPC to boot)? I know PostgreSQL v7.3.2 requires CygIPC
1.13.2-1, and I'd rather not downgrade to an older PostgreSQL, but I
don't think I have the time, let alone the skill, to go skulking around
in the source.

And if the CygIPC coder is AWOL, how does that affect PostgreSQL's plans
of being Windows native, if at all? And how exactly are they handling
the Win32 native port if not using Cygwin, and can those changes be used
to help roll the new IPC daemon?

I guess what I'd like to know is, is anyone out there successfully
running Windows XP Pro with the latest Cygwin and PostgreSQL 7.3.2?

Jason Tishler wrote:
> Frank,
>
> On Wed, Apr 30, 2003 at 12:55:40PM -0400, Frank Seesink wrote:
>
>>And no matter what, the following test was always the same when run
>>from the 'postgres' user account:
>>______________________________________________________________________
>>$ ipctest s
>>Test v0.03
>>Unable to create semaphore
>>semget : Function not implemented
>>______________________________________________________________________
>
>
> The above is the crux of your problem. Until you get the above to work,
> PostgreSQL is sure to fail. Sorry, but my only suggestion will require
> some effort. I recommend building a (debug-able) version of cygipc with
> tracing enabled. You may be able to determine what the problem is from
> the trace output. Otherwise, there is always gdb...

Actually, 2nd comment: I disagree with your analysis. As
mentioned in my original post, initdb works JUST FINE when run as the
administrative account that Cygwin was installed from.
Files/directories are created, and there are no errors. Though I
haven't done so yet, I'll bet that if I run postgres.exe using the
permissions of this administrator level account, the database will run
fine. [Once I have a chance to confirm this, I will update here.]

This, to me, indicates a permissions issue, NOT a coding issue.
...unless you are implying, without stating so, that CygIPC is
permissions-aware and goofing up with the new 'ntsec' default setting
somehow (though I can't for the life of me figure out how). But unless
I am mistaken, permissions are not handled within an application but by
the underlying OS (or in this case, Cygwin itself). If I build a basic
app under Unix and run it from a basic users account, I can't somehow
give myself root privileges (that would just be plain stupid). But I
can control who can read/execute the programs I compile in my account,
allowing others in my group or all to have access. This places
permissions management squarely down at the filesystem driver and OS levels.

I still maintain, as I wrote originally, that SOMETHING has changed
in the file permissions in the standard Cygwin distribution which is
causing PostgreSQL to break now where it did not before. As postings
indicate, this 'ntsec' feature used to be disabled by default, but is
now enabled by default. I find the coincidence a bit too much to swallow.

The problem, as I mentioned, is that I do not know WHERE this
permission issue lies: what folder/file needs adjusting, etc. But my
gut tells me that adjusting chmod settings somewhere in the Cygwin tree
may well resolve this issue. If anyone knows where to look, I am all ears.

Frank,

I just downloaded the latest cygwin, postgresql and ipc-daemon last week. I
am running on XP Home. This is my first experience with these software. You
may have noticed my messages for help. My postmaster kept dying no matter
what I did. It suddenly cleared up on Monday and I don't know why my
problems disappeared. I have created a couple of tables and done some
inserts and selects and so far it is working ok.

Vincent Hikida,
Member of Technical Staff - Urbana Software, Inc.
"A Personalized Learning Experience"

www.UrbanaSoft.com

----- Original Message -----
From: "Frank Seesink" <frank(at)mail(dot)wvnet(dot)edu>
To: <pgsql-cygwin(at)postgresql(dot)org>
Sent: Wednesday, April 30, 2003 4:05 PM
Subject: Re: [CYGWIN] initdb failure with PostgreSQL 7.3.2 / Cygwin 1.3.22-1
/

> Jason Tishler wrote:
> > Frank,
> >
> > On Wed, Apr 30, 2003 at 12:55:40PM -0400, Frank Seesink wrote:
> >
> >>And no matter what, the following test was always the same when run
> >>from the 'postgres' user account:
> >>______________________________________________________________________
> >>$ ipctest s
> >>Test v0.03
> >>Unable to create semaphore
> >>semget : Function not implemented
> >>______________________________________________________________________
> >
> >
> > The above is the crux of your problem. Until you get the above to work,
> > PostgreSQL is sure to fail. Sorry, but my only suggestion will require
> > some effort. I recommend building a (debug-able) version of cygipc with
> > tracing enabled. You may be able to determine what the problem is from
> > the trace output. Otherwise, there is always gdb...
>
> Oh, you're kidding, right? Please tell me you're kidding. Man, what
> has happened since the last time I did a Cygwin PostgreSQL install? It
> used to be so smooth...once you followed the instructions of
> course...which, by the way, thanks, Jason, for clearing up the starting
> of CygIPC before doing an initdb...the older versions of the doc were
> missing that step, and it took me awhile to figure it out when I was
> first starting with PostgreSQL under Cygwin.
>
> Am I truly unique in this situation, or are other people experiencing
> the same difficulty? From what I gather, I'm not alone. And I haven't
> found any definitve solution out there; only indications that CygIPC has
> bugs, and the developer is AWOL (or so you made it sound in another post
> I read).
>
> Is the answer to backpedal to an older version of PostgreSQL (and
> possibly CygIPC to boot)? I know PostgreSQL v7.3.2 requires CygIPC
> 1.13.2-1, and I'd rather not downgrade to an older PostgreSQL, but I
> don't think I have the time, let alone the skill, to go skulking around
> in the source.
>
> And if the CygIPC coder is AWOL, how does that affect PostgreSQL's plans
> of being Windows native, if at all? And how exactly are they handling
> the Win32 native port if not using Cygwin, and can those changes be used
> to help roll the new IPC daemon?
>
> I guess what I'd like to know is, is anyone out there successfully
> running Windows XP Pro with the latest Cygwin and PostgreSQL 7.3.2?
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>

Frank,

On Wed, Apr 30, 2003 at 07:05:53PM -0400, Frank Seesink wrote:
> Jason Tishler wrote:
> >The above is the crux of your problem. Until you get the above to
> >work, PostgreSQL is sure to fail. Sorry, but my only suggestion will
> >require some effort. I recommend building a (debug-able) version of
> >cygipc with tracing enabled. You may be able to determine what the
> >problem is from the trace output. Otherwise, there is always gdb...
>
> Oh, you're kidding, right? Please tell me you're kidding.

Sorry, no. However, see my next post...

> Man, what has happened since the last time I did a Cygwin PostgreSQL
> install?

Your previous post seemed to indicate that this was you first XP Pro
install (the others were on 2000). For some reasons, XP Pro seems to
give Cygwin PostgreSQL users problems...

> Is the answer to backpedal to an older version of PostgreSQL (and
> possibly CygIPC to boot)?

IMO, no.

> I guess what I'd like to know is, is anyone out there successfully
> running Windows XP Pro with the latest Cygwin and PostgreSQL 7.3.2?

I have been successful. AFAICT, XP Pro behaves identical to 2000 with
respect to Cygwin PostgreSQL.

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Frank,

On Wed, Apr 30, 2003 at 07:08:46PM -0400, Frank Seesink wrote:
> Jason Tishler wrote:
> >Frank,
> >
> >On Wed, Apr 30, 2003 at 12:55:40PM -0400, Frank Seesink wrote:
> >
> >>And no matter what, the following test was always the same when run
> >>from the 'postgres' user account:
^^^^^^^^
********

> >>____________________________________________________________________
> >>$ ipctest s
> >>Test v0.03
> >>Unable to create semaphore
> >>semget : Function not implemented
> >>____________________________________________________________________
> >
> >The above is the crux of your problem. Until you get the above to
> >work, PostgreSQL is sure to fail.

Sorry, I should have been more clear. I meant getting "ipctest s" to
work when run under the postgres user account.

> >Sorry, but my only suggestion will require some effort. I recommend
> >building a (debug-able) version of cygipc with tracing enabled. You
> >may be able to determine what the problem is from the trace output.
> >Otherwise, there is always gdb...
>
> Actually, 2nd comment: I disagree with your analysis. As
> mentioned in my original post, initdb works JUST FINE when run as the
> administrative account that Cygwin was installed from.

Understood. This is why I suggested tracing and gdb, because I can't
understand why initdb fails for postgres but succeeds for another user.

Let's try another approach. Please strace "ipctest s" when run under
the postgres:

$ strace -o ipctest.log ipctest s

and post ipctest.log to the list. Remember to start ipc-daemon before
running the strace.

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Jason Tishler wrote:
...
> Let's try another approach. Please strace "ipctest s" when run under
> the postgres:
>
> $ strace -o ipctest.log ipctest s
>
> and post ipctest.log to the list. Remember to start ipc-daemon before
> running the strace.

As requested, attached here is ipctest.log, run as user 'postgres'
after making sure ipc-daemon was started. If the attachment doesn't
work for some reason, please let me know and I'll repost by copy/pasting
the contents here in the body.

More interesting news: After looking over the various posts, and going
with my gut, I decided to do an identical install on a test box I
luckily have handy.

Basically, the EXACT same configuration...same rev of
setup.exe/cygwin/cygipc/etc., same install steps, etc....but this time
the box was a Windows 2000 SP3 box with all updates thru today, as
opposed to Windows XP Pro. That was the only real difference. And it
WORKS!

* ipc-daemon installs and runs fine (just like before)
* but now, user 'postgres' CAN create the tables with the
'initdb -D ...' command, and tests of 'ipctest s' are
susccessful.

HOWEVER, and this is KEY, the FILE PERMISSIONS OF THIS INSTALL ARE
TOTALLY DIFFERENT FROM WINDOWS XP!!!

In short, the Windows 2000 install looks like it totally ignores the
file permissions. EVERYTHING is tagged as chmod 777, from the root on
down. And that got me thinking.

So I started comparing. What struck me is that--for lack of a nicer
way of saying it--in Windows XP, chmod appears to actually have an
effect, whereas in Windows 2000 it does not. Everything in Windows 2000
was tagged for the world to do whatever it wanted with the files. In
Windows XP, only /home was set that way during install. And I had to
modify /tmp (chmod 777) and /bin--a.k.a. /usr/bin-- and /usr/bin/*
(chmod a+rx) so that everyone could execute what was in those directories.

However, looking further, what I see now is that almost everything else
under Windows XP (what I have not touched) is defaulted to chmod
770...including /var and almost everything in it!!! (except /var/cron).
Also /usr/var, and...well, basically, most of the files.
______________________________________________________________________
$ cd /var
$ ls -al
total 0
drwxrwx---+ 9 Frank Users 0 Apr 29 11:03 .
drwxrwx---+ 10 Frank Users 0 Apr 29 17:37 ..
drwxrwx---+ 4 Frank Users 0 Apr 29 10:48 cache
drwxrwxrwt+ 3 Frank Users 0 Apr 29 11:03 cron
drwxrwx---+ 4 Frank Users 0 Apr 29 11:06 log
drwxrwx---+ 2 Frank Users 0 Apr 29 10:39 run
drwxrwx---+ 5 Frank Users 0 Apr 29 11:03 spool
drwxrwx---+ 2 Frank Users 0 Apr 29 10:39 tmp
drwxrwx---+ 5 Frank Users 0 Apr 29 10:40 www
______________________________________________________________________

Files in /etc have various permissions. Some allow read/write by the
world, others only read, others read/execute, and some neither.

Files in /lib have permissions set as -rwxr-x---+ , whereas directories
also have group write capability.

Mind you, this is the EXACT SAME INSTALL I did on the Windows 2000 SP3
box...same version of EVERYTHING.
______________________________________________________________________
To try to determine whether some file permission was biting me, I
started systematically 'opening' the file permissions on my WinXP Cygwin
install. First I did the following:

$ chmod 777 /usr/tmp /usr/var
$ chmod 777 /var /var/*
$ chmod -R 777 /var/cache/*
$ chmod 777 /var/log/apache

And retried 'initdb -D' under 'postgres'. No good. Exact same error
(same semget numbers EXACTLY...EVERY time).
______________________________________________________________________
Next I tried opening up access to the PostgreSQL data directories:

$ mkdir /usr/share/postgresql/data
$ chown postgres:Users /usr/share/postgresql/data
$ cd /usr/share/postgresql
$ chmod 777 data
$ chmod -R a+rx contrib
$ chmod a+rx conversion_create.sql
$ chmod -R a+rx java
$ chmod a+rx *

Nope. Still same error. Problem appears definitely with CygIPC. I
just can't seem to create a semaphore under 'postgres', but it's ok
under an Administrator account.
______________________________________________________________________
Next I started digging into the Cygwin docs, eventually reading and
re-reading the following:

http://cygwin.com/cygwin-ug-net/ntsec.html#NTSEC-FILES

I did find out why the heck 'postgres' was listing with a 'None' group
setting, vs. my administrator account showing with a 'Users' setting.
So that I fixed by modifying the /etc/passwd file. But that had no
bearing on anything in the end. *sigh*

It definitely seems that with Cygwin 1.3.20, things started changing
file permissions-wise. I suspect this is when 'ntsec' became a default
setting (something that should have been accompanied with a BIG WARNING
to users in my book, but whatever). But I have tried (several days ago)
to disable all this by setting

CYGWIN=nontsec

but to no avail. Haven't tried it here today or yesterday, but see no
reason why it would magically make a difference now. I'll try that
tomorrow if I can. But I expect nothing.
______________________________________________________________________
Anyway, the probably clearly IS that I am unable to create semaphores
(using things like 'ipctest s') running as 'postgres', but I can't for
the life of me figure out why. What makes the EXACT same version of
Cygwin/CygIPC/PostgreSQL WORK under Windows 2000 but NOT under Windows
XP??? I don't recall any major changes between the OS versions that
would impact things here...except possibly the change in the NTFS file
format (again, file permissions-related).

CygIPC simply creates semaphores and stores them in the files in /tmp,
and I have that folder and those files set WIDE open. (I even tested
doing an 'echo HAHA >> /tmp/MultiShm' and it worked from 'postgres', so
I know directly writing into the file is not a problem.)

So why can't I create a 'semaphor'? I even tried running CygIPC under
the context of user 'postgres', thereby eliminating any potential weird
Win2K/WinXP 'features' that might have crept in. If CygIPC runs as
'postgres', it makes no difference. Still no go.

But if I am running as the user with Administrative rights that I
installed Cygwin and CygIPC with, it's fine. And it's not like it has
some requirement that I am THE Administrator (i.e., RID 500 in the NT
world), as I am using a regular account (RID above 1000) that happens to
be a member of the Administrators group, and that works.

But I just can't figure out what is different. I have even tried adding
user 'postgres' to the Administrators group and THEN tried creating a
semaphore, but still no go.

Running as 'postgres' as a member of the Administrators group, I then did

$ net stop ipc-daemon
$ ipc-daemon --remove-as-service
$ rm /tmp/Multi*
$ ipc-daemon --install-as-service
$ net start ipc-daemon
$ ipctest s

and it STILL fails!! But as the admin user, I CAN create semaphores!!!
GAAAH!

I'm quickly running out of ideas. This is a level of frustration I
have NEVER felt when dealing with PostgreSQL under Cygwin. My earlier
failures (more than a year ago) could easily be attributed to
inexperience. But I have done this literally dozens of times now, and I
know most of the minefields. Only now am I experiencing this hell.

My gut still tells me it's some kind of permissions issue, but who
knows. Maybe CygIPC is hooking into some feature of the Windows API
that is somehow just...so...slightly...different in XP. Beats me. I
just find it interesting and a bit unnerving when I read things like

http://cygwin.com/ml/cygwin-announce/2003-03/msg00025.html

where Christopher Faylor of Red Hat, Inc. writes

...
Changes since 1.3.21-1 (worst cygwin release ever):
... ^^^^^^^^^^^^^^^^^^^^^^^^^

Ouch.
Uh oh.

Here's to hoping for a solid, native port of PostgreSQL to Windows, or
else a cleanup of whatever is ailing Cygwin/CygIPC. Ideally, if it's
true the developer of CygIPC has gone AWOL, here's to hoping someone
gets that replacement Cygwin IPC daemon done sometime REAL soon.

If anyone has any other suggestions, please throw 'm at me.

Frank,

On Thu, May 01, 2003 at 10:21:14AM -0400, Frank Seesink wrote:
> Jason Tishler wrote:
> ...
> >Let's try another approach. Please strace "ipctest s" when run under
> >the postgres:
> >
> > $ strace -o ipctest.log ipctest s
>
> As requested, attached here is ipctest.log, run as user 'postgres'
> after making sure ipc-daemon was started.

Your strace (i.e., ipctest-frank.log) yields the following:

$ fgrep 'errno 88' ipctest-frank.log
67 46182 [main] ... writev: 27 = write (1, 0x22FBA0, 1), errno 88
53 46505 [main] ... writev: 7 = write (2, 0x22FBA0, 1), errno 88
58 46837 [main] ... writev: 2 = write (2, 0x22FBA0, 1), errno 88
60 47264 [main] ... writev: 24 = write (2, 0x22FBA0, 1), errno 88
53 47586 [main] ... writev: 1 = write (2, 0x22FBE0, 1), errno 88

My strace with ipc-daemon running yields the following:

$ ps -ef | fgrep ipc-daemon
system 2264 1 ? 07:29:28 /usr/local/bin/ipc-daemon
$ strace ipctest s | fgrep 'errno 88'
$

My strace without ipc-daemon running yields the following:

$ ps -ef | fgrep ipc-daemon
$ strace ipctest s 2>/dev/null | fgrep 'errno 88'
152 37428 [main] ... writev: 7 = write (2, 0x22FBA0, 1), errno 88
76 37739 [main] ... writev: 2 = write (2, 0x22FBA0, 1), errno 88
75 38151 [main] ... writev: 24 = write (2, 0x22FBA0, 1), errno 88
106 38485 [main] ... writev: 1 = write (2, 0x22FBE0, 1), errno 88
75 38799 [main] ... writev: 38 = write (1, 0x22FE18, 1), errno 88

Hence, your strace is very similar to what I get when ipc-daemon is
*not* running.

My WAG from the above is that for some reason the following cygipc code
is failing on your XP Pro SP1 setup:

static int IsGSemSemExist()
{
GSemSem = OpenSemaphore(SEMAPHORE_ALL_ACCESS, FALSE, CYGWIN_IPCNT_SEMSEM);
if( GSemSem != NULL )
{
return (1) ;
} else {
return (0) ;
}
}

Please run the attached program under both the Frank and postgres user
accounts to confirm or refute the above hypothesis and report back to
the list.

BTW, I just thought of a potential workaround. What happens if you run
ipc-daemon under the postgres account. Does "ipctest s" under postgres
work? Does initdb work? Remember to delete the /tmp files created by
ipc-daemon before trying.

Thanks,
Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Jason Tishler wrote:
...[snip]...
> Your strace (i.e., ipctest-frank.log) yields the following:
>
> $ fgrep 'errno 88' ipctest-frank.log
> 67 46182 [main] ... writev: 27 = write (1, 0x22FBA0, 1), errno 88
> 53 46505 [main] ... writev: 7 = write (2, 0x22FBA0, 1), errno 88
> 58 46837 [main] ... writev: 2 = write (2, 0x22FBA0, 1), errno 88
> 60 47264 [main] ... writev: 24 = write (2, 0x22FBA0, 1), errno 88
> 53 47586 [main] ... writev: 1 = write (2, 0x22FBE0, 1), errno 88
>
> My strace with ipc-daemon running yields the following:
>
> $ ps -ef | fgrep ipc-daemon
> system 2264 1 ? 07:29:28 /usr/local/bin/ipc-daemon
> $ strace ipctest s | fgrep 'errno 88'
> $
>
> My strace without ipc-daemon running yields the following:
>
> $ ps -ef | fgrep ipc-daemon
> $ strace ipctest s 2>/dev/null | fgrep 'errno 88'
> 152 37428 [main] ... writev: 7 = write (2, 0x22FBA0, 1), errno 88
> 76 37739 [main] ... writev: 2 = write (2, 0x22FBA0, 1), errno 88
> 75 38151 [main] ... writev: 24 = write (2, 0x22FBA0, 1), errno 88
> 106 38485 [main] ... writev: 1 = write (2, 0x22FBE0, 1), errno 88
> 75 38799 [main] ... writev: 38 = write (1, 0x22FE18, 1), errno 88
>
> Hence, your strace is very similar to what I get when ipc-daemon is
> *not* running.

That seems reasonable. The impression I get is that running as user
'postgres' programs don't 'see' the CygIPC daemon. But I can't figure
out why. And since you mentioned in another post that you've had it
working just fine, it makes me wonder what, if anything, I've done on
these XP installs that would 'block' that ability. (I tend to harden
boxes I setup...comes with the territory...but sometimes the measures we
take to protect a Windows box inadvertently breaks a feature we need. I
just wish I could figure out what that was.)

> My WAG from the above is that for some reason the following cygipc code
> is failing on your XP Pro SP1 setup:
>
> static int IsGSemSemExist()
> {
> GSemSem = OpenSemaphore(SEMAPHORE_ALL_ACCESS, FALSE, CYGWIN_IPCNT_SEMSEM);
> if( GSemSem != NULL )
> {
> return (1) ;
> } else {
> return (0) ;
> }
> }

Again, sounds about right. As user 'postgres', initdb cannot seem to
see the IPC daemon, so this function returning 0 makes sense.

> Please run the attached program under both the Frank and postgres user
> accounts to confirm or refute the above hypothesis and report back to
> the list.

FYI: Your .EXE was ripped out by an email virusscanner it appears
(either ours or Gmane's...can't tell which), and I have the following
warning at the head of your email:

Warning: This message has had one or more attachments removed
Warning: (cit.exe).
Warning: Please read the "VirusWarning.txt" attachment(s) for more
information.

So what's involved in compiling this code? Just straightforward 'gcc -o
cit.exe cit.c' ? Forgive my being just a tad leary. I'm sure the code
is legit. I just figured I'd ask first to verify that you did send me
an .EXE. :-)

> BTW, I just thought of a potential workaround. What happens if you run
> ipc-daemon under the postgres account. Does "ipctest s" under postgres
> work? Does initdb work? Remember to delete the /tmp files created by
> ipc-daemon before trying.

Actually, if you read my posts from last night, you'll see I've already
covered that ground...and then some. (Heck, 'postgres' wouldn't work
when I made it an Administrator account!!!) Not sure why it's being
such a pain under XP.

Do you happen to know what default security changes MS may have made in
XP, say in the 'Local Security Policies', between 2000 & XP? I know of
a few, but none really apply. And I've tried changing quite a few that
I thought in some bizarre way might play a role, but have had no luck so
far.

Jason Tishler wrote:
...[snip]...
> Please run the attached program under both the Frank and postgres user
> accounts to confirm or refute the above hypothesis and report back to
> the list.

Confirmed. Here's the output run as both 'Frank' (the admin level
acct) and 'postgres':
______________________________________________________________________
Frank(at)SEESINK /tmp
$ ./cit
1892 = OpenSemaphore() succeeded
______________________________________________________________________
postgres(at)SEESINK /tmp
$ ./cit
OpenSemaphore() failed with last error = 2
______________________________________________________________________

Note that if I shutdown CygIPC and run the command from 'Frank', the
results are identical to the 'postgres' results. So yes, indeed, it
looks as if to the 'postgres' user, CygIPC does not exist/is not
responding/cannot be accessed. Now the mother of all questions: why?
Why does it work for you and not for me in XP?

Do you run a vanilla XP config? If not, what changes if any do you
make? I can't think of any apps which would get in the way of this, but
then, I'm not 100% clear on how CygIPC is contacted. And as mentioned,
I've tried running CygIPC AS user 'postgres', and even that did not work.

> BTW, I just thought of a potential workaround. What happens if you run
> ipc-daemon under the postgres account. Does "ipctest s" under postgres
> work? Does initdb work? Remember to delete the /tmp files created by
> ipc-daemon before trying.

As mentioned in my last post, way ahead of you. And yes, I always make
sure when I shutdown CygIPC to delete the /tmp/Multi* files. I've
gotten in that habit over time.

Frank,

On Fri, May 02, 2003 at 12:25:33PM -0400, Frank Seesink wrote:
> Jason Tishler wrote:
> (I tend to harden boxes I setup...comes with the territory...but
> sometimes the measures we take to protect a Windows box inadvertently
> breaks a feature we need. I just wish I could figure out what that
> was.)

The above could be an explanation.

> >Please run the attached program under both the Frank and postgres
> >user accounts to confirm or refute the above hypothesis and report
> >back to the list.
>
> FYI: Your .EXE was ripped out by an email virusscanner it appears
> (either ours or Gmane's...can't tell which), and I have the following
> warning at the head of your email:

I provided the source for exactly the above reason. Anyway, you can
download a pre-built version from here:

http://archives.postgresql.org/pgsql-cygwin/2003-05/bin00000.bin

or build it yourself.

> So what's involved in compiling this code? Just straightforward 'gcc
> -o cit.exe cit.c' ?

Yes.

> Forgive my being just a tad leary.

No problem.

> I'm sure the code is legit. I just figured I'd ask first to verify
> that you did send me an .EXE. :-)

Yes, I attempted to send an executable.

> >BTW, I just thought of a potential workaround. What happens if you
> >run ipc-daemon under the postgres account. Does "ipctest s" under
> >postgres work? Does initdb work? Remember to delete the /tmp files
> >created by ipc-daemon before trying.
>
> Actually, if you read my posts from last night, you'll see I've
> already covered that ground...and then some.

Yes, I read it but after responding to your previous post.

> Do you happen to know what default security changes MS may have made
> in XP, say in the 'Local Security Policies', between 2000 & XP?

No, but this is another area to investigate. However, remember that I
recently tried installing PostgreSQL on XP Pro SP1 and it behaved just
like 2000 SP3 for me.

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

[This is my 3rd attempt to get this post to 'stick'. Not sure why I'm
having such difficulty in posting to the mailing list, but it's a little
annoying. Anyway, gave up on the GIF attachment. Take my word for it,
ipc-daemon IS running according to Windows. Now here goes...]

Yet more confusing data to work with:

I tried once again adding 'postgres' to the Administrators group
(otherwise I can't do 'net stop'/'net start' as user 'postgres', and I
wanted to in order to confirm something). Steps taken were as follows:

(Note that unless otherwise noted, I am not logging off/on but just fast
user context switching between accounts to save time.)

1. Logged completely off as 'postgres' (to free up 'keyring' of
security settings)
2. Signed back in as admin user 'Frank', and added 'postgres' to
Administrators group.
3. Changed ipc-daemon's NT service settings to log in under the
'postgres' user context, making sure to type in password properly,
blah blah blah.
3. Ran BASH and entered following:
$ net stop ipc-daemon
$ rm /tmp/Multi*
$ exit
4. Did a switch user, then logged in as 'postgres'
5. Ran BASH and entered following:
______________________________________________________________________
postgres(at)SEESINK /tmp
$ net start ipc-daemon
The Cygwin IPC Daemon service is starting.
The Cygwin IPC Daemon service was started successfully.

postgres(at)SEESINK /tmp
$ ls -al
total 4070
drwxrwxrwx+ 4 Frank Users 0 May 2 13:15 .
drwxrwx---+ 10 Frank Users 0 Apr 29 17:37 ..
drwxrwxrwx+ 3 Frank None 0 Apr 29 11:40 CygIPC
-rw-rw-rw- 1 postgres Users 3916520 May 2 13:15 MultiFileMsg
-rw-rw-rw- 1 postgres Users 22032 May 2 13:15 MultiFileSem
-rw-rw-rw- 1 postgres Users 202768 May 2 13:15 MultiFileShm
...[clip]

postgres(at)SEESINK /tmp
$ ps -ef
UID PID PPID TTY STIME COMMAND
postgres 120 1 con 13:13:59 /usr/bin/bash
postgres 892 120 con 13:17:25 /usr/bin/ps
______________________________________________________________________
6. Notice anyting missing in the 'ps' command? Yeah, right. The
ipc-daemon!!! But if I bring up the NT Task Manager (see attached
GIF), it's there. Oh yeah, and the usual 'ipctest s' cmd failed
as it always has thus far.
7. Log completely out of 'postgres', sign back in as 'Frank', run BASH:
______________________________________________________________________
Frank(at)SEESINK ~
$ ps -ef
UID PID PPID TTY STIME COMMAND
Frank 3788 1 con 13:13:17 /usr/bin/bash
postgres 948 1 ? 13:15:39 /usr/local/bin/ipc-daemon
Frank 3596 3788 con 13:27:21 /usr/bin/ps
______________________________________________________________________
8. Now ipc-daemon shows. What the...?!?!? I don't get it. It's as if
CYGWIN itself does not see the running process at all when I'm
logged in as 'postgres'. Why would THAT be? How does Cygwin
determine/maintain its list of running processes? Obviously 'ps'
does not show all running NT processes, but rather only those
running in a Cygwin context. But where is that maintained, and why
is it that as 'postgres' I do not see that information?

Again, currently 'postgres' has been given Administrator level
privileges as far as WinXP is concerned.

Ok, looks my non-attachment attempt worked. So I'll repeat something I
asked in private:

I have spent the better part of the afternoon digging back thru the last
4 months of postings. One thing caught my eye.

Jason, you mention repeatedly about a file

/tmp/cygipc_0

But I have yet to see that file on XP (where PostgreSQL is NOT working)
_OR_ Windows 2000 (where the exact same install IS working). All I see
are the /tmp/MultiFile* files.

Is this file you mention still valid now? And if so, how do you explain
the Windows 2000 box working properly? I'm confused.

Or does the /tmp/cygipc_0 only show up when postmaster itself is run,
kind of like a PID file or other filelocking mechanism? Please note I
have only been working thus far with the test command 'ipctest s' and
the 'initdb' command. I have yet to fire up postgres itself yet.

More info:

* Reset everything to the way things 'normally' would be (user
'postgres' only a member of 'Users', ipc-daemon configured to run as
Local System account, etc.).
* Logged in as 'Frank' (aka, admin acct), made sure /tmp/MultiFile* was
removed, then did 'net start ipc-daemon' to bring IPC up.
* Made sure /tmp/MultiFile* files were there and world read/writable.
* ran 'ipctest s' and successfully created semaphore 0. Did a few more
and all worked.
* Switched out and logged in as 'postgres', brought up BASH, and tried
'ipctest s', and failed as usual.
* Did a 'ps' and saw only the shell and the ps command...no ipc-daemon.
* For fun, tried 'ipc-daemon &', and it fired up!
* Ran 'ps' again and confirmed that ipc-daemon was now listed.
* Ran 'ipctest s' now, and it worked!

Interesting thing to note, though, is that the command created semaphore
0 all over again. It's as if the copy of ipc-daemon running in the
'postgres' context is oblivious to the copy running as Local System
account. It created a semaphore with the same index number (normally it
seems to increment by 1 each time, and if you do 'ipck all' to kill off
all the semaphores, the next one you create is like 4-500 higher in
number...doesn't continue the sequence in order).

When I kill postgres' ipc-daemon, close BASH, log out, and switch back
to user 'Frank' and do 'ipctest s', that works as well. Obviously as
'Frank' I'm accessing the service copy of ipc-daemon.

Now here are a few other items floating around in my noggin. I do know
for a fact that Microsoft has changed the file permission settings for
the root level of their drives between Windows 2000 and Windows XP.
That is, when I did base installs of Win2K and WinXP, I found that the
permissions on C:\, D:\, etc., were much tighter under XP than they were
under Win2K. I didn't do a full comparative analysis, but let's just
say I ran into some interesting permission issues thanks to that in the
past. Whereas the default in Win2K is something along the order of
Everyone has full rights (and then the install closes down those rights
for \WINNT, etc.), in WinXP the root level is much tighter, and it is
inherited down the tree. This required my overriding the permissions at
the root level on data partitions of some systems in order to make
Windows version of 'mounting' work properly.

Note the XP boxes (one desktop and one laptop) I've been trying this
out on still have their basic permissions set for the system partitions.
However, the initial XP box I worked on I had overridden those
permissions by opening them up (giving Everyone full rights at the root
level) on the data partition. However, this should have no bearing, as
Cygwin was installed on the C:\ system partition.

So that brings me back to file permissions once again...though the fact
that 'postgres' does not even SEE ipc-daemon makes me wonder just where
the trouble lies. Now for the big question: If I set the environment
variable 'CYGWIN=nontsec' and reboot, will that truly rule out file
permissions as a culprit?

I get the impression that this whole ntsec business isn't the cleanest
thing. I can't imagine exactly how they overlaid the *nix file
permissions on an NT file system, as they are so different in nature
(basic owner/group/world permissions versus ACLs). Throw in the whole
'Everyone' vs. 'Authenticated Users' business in NT, and who knows what
else... ANYWAY, my point is this: If I set CYGWIN as stated, reboot,
and try again, what will this definitely say, if anything?

Set system environment variable CYGWIN=nontsec, rebooted, and tried it
all again. BZZZZ! Wrong! Thanks for playing. Nope, still no good.

So ntsec isn't the issue.

Next question: I notice on the webpage for CygIPC, Jason, that you are
a large contributor to fixes that are in 1.13. The webpage makes it
sound, however, like CygIPC 1.11 and 1.13 are basically the same ("1.13
is a backward compatible, drop-in replacement for cygipc-1.11").

Would it make sense to try CygIPC 1.11 to see if that worked? Or is it
a known fact that PostgreSQL 7.3.2 must have CygIPC 1.13? From all I
gathered, 1.13 was required for 7.3.2, so I never tried going backwards.
Just figured I'd ask to be sure.

Frank,

On Fri, May 02, 2003 at 05:37:11PM -0400, Frank Seesink wrote:
> Ok, looks my non-attachment attempt worked. So I'll repeat something I
> asked in private:
>
> I have spent the better part of the afternoon digging back thru the last
> 4 months of postings. One thing caught my eye.
>
> Jason, you mention repeatedly about a file
>
> /tmp/cygipc_0
>
> But I have yet to see that file on XP (where PostgreSQL is NOT working)
> _OR_ Windows 2000 (where the exact same install IS working). All I see
> are the /tmp/MultiFile* files.
>
> Is this file you mention still valid now?

Yes.

> And if so, how do you explain the Windows 2000 box working properly?
> I'm confused.

See below...

> Or does the /tmp/cygipc_0 only show up when postmaster itself is run,

Yes, when postmaster calls shmget().

> kind of like a PID file or other filelocking mechanism?

No, this file is used by cygipc's SysV shared memory implementation.

> Please note I have only been working thus far with the test command
> 'ipctest s' and the 'initdb' command. I have yet to fire up postgres
> itself yet.

The above explains why you have not seen this file yet.

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Frank,

On Fri, May 02, 2003 at 06:42:14PM -0400, Frank Seesink wrote:
> Set system environment variable CYGWIN=nontsec, rebooted, and tried it
> all again. BZZZZ! Wrong! Thanks for playing. Nope, still no good.
>
> So ntsec isn't the issue.
>
> Next question: I notice on the webpage for CygIPC, Jason, that you
> are a large contributor to fixes that are in 1.13. The webpage makes
> it sound, however, like CygIPC 1.11 and 1.13 are basically the same
> ("1.13 is a backward compatible, drop-in replacement for
> cygipc-1.11").

Yes, 1.11 and 1.13 are basically the same. However, the cygipc
maintainer changed at least one pathname (i.e., /tmp/cygipc vs.
/tmp/cygipc_) which breaks compatibility.

> Would it make sense to try CygIPC 1.11 to see if that worked?

No.

> Or is it a known fact that PostgreSQL 7.3.2 must have CygIPC 1.13?
> From all I gathered, 1.13 was required for 7.3.2, so I never tried
> going backwards. Just figured I'd ask to be sure.

Yes, see above. Actually, IIRC, 1.13-2 is required -- even 1.13-1 won't
work. Sigh...

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Frank,

On Fri, May 02, 2003 at 12:58:22PM -0400, Frank Seesink wrote:
> Jason Tishler wrote:
> ...[snip]...
> >Please run the attached program under both the Frank and postgres
> >user accounts to confirm or refute the above hypothesis and report
> >back to the list.
>
> Confirmed. Here's the output run as both 'Frank' (the admin level
> acct) and 'postgres':
> ______________________________________________________________________
> Frank(at)SEESINK /tmp
> $ ./cit
> 1892 = OpenSemaphore() succeeded
> ______________________________________________________________________
> postgres(at)SEESINK /tmp
> $ ./cit
> OpenSemaphore() failed with last error = 2
> ______________________________________________________________________

The above is very interesting. I expected cit to fail under postgres
but not with a last error of 2:

$ fgrep 2L /usr/include/w32api/winerror.h | head -1
#define ERROR_FILE_NOT_FOUND 2L

Actually, I expected a last error of 5:

$ fgrep 5L /usr/include/w32api/winerror.h | head -1
#define ERROR_ACCESS_DENIED 5L

Hence, your problem appears to be more insidious than a simple
permissions problem.

> Note that if I shutdown CygIPC and run the command from 'Frank', the
> results are identical to the 'postgres' results. So yes, indeed, it
> looks as if to the 'postgres' user, CygIPC does not exist/is not
> responding/cannot be accessed. Now the mother of all questions: why?
> Why does it work for you and not for me in XP?

I don't know. I appears that the semaphores created by ipc-daemon are
not accessible by users other than Frank.

I have another idea. Please download the handle utility from
Sysinternals:

http://www.sysinternals.com/ntw2k/freeware/handle.shtml

run the following when ipc-daemon is running under LocalSystem:

$ handle -a -p ipc-daemon | fgrep Multi
d8: Semaphore \BaseNamedObjects\MultiSemCtl_
dc: Semaphore \BaseNamedObjects\MultiSemSem_
e0: Semaphore \BaseNamedObjects\MultiSemShm_
e4: Semaphore \BaseNamedObjects\MultiSemMsg_
e8: File C:\Cygwin\tmp\MultiFileSem
f0: File C:\Cygwin\tmp\MultiFileShm
f8: File C:\Cygwin\tmp\MultiFileMsg

and post your results to the list.

> Do you run a vanilla XP config?

I did not install the XP box that I'm testing on, but I believe that it
is "vanilla."

> If not, what changes if any do you make?

I will check with the installer, but assume that none were made unless I
indicate otherwise.

> I can't think of any apps which would get in the way of this, but
> then, I'm not 100% clear on how CygIPC is contacted.

ipc-daemon is contacted by opening semaphores -- exactly how cit does
it. If not, why would I ask you to run cit?

> And as mentioned, I've tried running CygIPC AS user 'postgres', and
> even that did not work.

The above is truly amazing!

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Frank,

On Fri, May 02, 2003 at 05:21:30PM -0400, Frank Seesink wrote:
> (Note that unless otherwise noted, I am not logging off/on but just
> fast user context switching between accounts to save time.)

Until we get to the bottom of this, please do *not* do the above. In
this way, we can at least remove one variable.

> postgres(at)SEESINK /tmp
> $ net start ipc-daemon
> The Cygwin IPC Daemon service is starting.
> The Cygwin IPC Daemon service was started successfully.
>
> [snip]
>
> postgres(at)SEESINK /tmp
> $ ps -ef
> UID PID PPID TTY STIME COMMAND
> postgres 120 1 con 13:13:59 /usr/bin/bash
> postgres 892 120 con 13:17:25 /usr/bin/ps
> ______________________________________________________________________
> 6. Notice anyting missing in the 'ps' command? Yeah, right. The
> ipc-daemon!!! But if I bring up the NT Task Manager (see attached
> GIF), it's there.

YA truly amazing occurrence. Please run Sysinternal's handle with the
above setup:

$ handle -a -p ipc-daemon | fgrep Multi

Do you get the expected output (from my previous post)?

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Frank,

On Fri, May 02, 2003 at 06:11:06PM -0400, Frank Seesink wrote:
> More info:
>
> * Reset everything to the way things 'normally' would be (user
> 'postgres' only a member of 'Users', ipc-daemon configured to run as
> Local System account, etc.).
> [snip]
> * Switched out and logged in as 'postgres', brought up BASH, and tried
> 'ipctest s', and failed as usual.
> * Did a 'ps' and saw only the shell and the ps command...no ipc-daemon.

Did you do a "ps" or a "ps -ef"? With the former, ipc-daemon should not
be displayed since it was running under a different user.

> * For fun, tried 'ipc-daemon &', and it fired up!

YA truly amazing occurrence. The above should have failed as follows:

$ ipc-daemon
(ipc-daemon) IPC-daemon is already started !!

> [snip]
>
> It's as if the copy of ipc-daemon running in the 'postgres' context is
> oblivious to the copy running as Local System account.

Yes. I believe understanding the above will lead to the root cause of
this problem.

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Frank,

On Mon, May 05, 2003 at 08:13:01AM -0400, Jason Tishler wrote:
> On Fri, May 02, 2003 at 06:11:06PM -0400, Frank Seesink wrote:
> > It's as if the copy of ipc-daemon running in the 'postgres' context
> > is oblivious to the copy running as Local System account.
>
> Yes. I believe understanding the above will lead to the root cause of
> this problem.

I did some more Googling. Does the following apply to your setup?

http://support.microsoft.com/default.aspx?scid=kb;en-us;264651

If so, then try switching Terminal Services to Application Server mode.
Does this have any affect?

Thanks,
Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Ok, here come the responses...

Jason Tishler wrote:
> Frank,
>
> On Fri, May 02, 2003 at 12:58:22PM -0400, Frank Seesink wrote:
>
>>Jason Tishler wrote:
>>...[snip]...
>>
>>>Please run the attached program under both the Frank and postgres
>>>user accounts to confirm or refute the above hypothesis and report
>>>back to the list.
>>
>>Confirmed. Here's the output run as both 'Frank' (the admin level
>>acct) and 'postgres':
>>______________________________________________________________________
>>Frank(at)SEESINK /tmp
>>$ ./cit
>>1892 = OpenSemaphore() succeeded
>>______________________________________________________________________
>>postgres(at)SEESINK /tmp
>>$ ./cit
>>OpenSemaphore() failed with last error = 2
>>______________________________________________________________________
>
>
> The above is very interesting. I expected cit to fail under postgres
> but not with a last error of 2:
>
> $ fgrep 2L /usr/include/w32api/winerror.h | head -1
> #define ERROR_FILE_NOT_FOUND 2L
>
> Actually, I expected a last error of 5:
>
> $ fgrep 5L /usr/include/w32api/winerror.h | head -1
> #define ERROR_ACCESS_DENIED 5L
>
> Hence, your problem appears to be more insidious than a simple
> permissions problem.
>
>
>>Note that if I shutdown CygIPC and run the command from 'Frank', the
>>results are identical to the 'postgres' results. So yes, indeed, it
>>looks as if to the 'postgres' user, CygIPC does not exist/is not
>>responding/cannot be accessed. Now the mother of all questions: why?
>>Why does it work for you and not for me in XP?
>
>
> I don't know. I appears that the semaphores created by ipc-daemon are
> not accessible by users other than Frank.
>
> I have another idea. Please download the handle utility from
> Sysinternals:
>
> http://www.sysinternals.com/ntw2k/freeware/handle.shtml
>
> run the following when ipc-daemon is running under LocalSystem:
>
> $ handle -a -p ipc-daemon | fgrep Multi
> d8: Semaphore \BaseNamedObjects\MultiSemCtl_
> dc: Semaphore \BaseNamedObjects\MultiSemSem_
> e0: Semaphore \BaseNamedObjects\MultiSemShm_
> e4: Semaphore \BaseNamedObjects\MultiSemMsg_
> e8: File C:\Cygwin\tmp\MultiFileSem
> f0: File C:\Cygwin\tmp\MultiFileShm
> f8: File C:\Cygwin\tmp\MultiFileMsg
>
> and post your results to the list.

Here you go, run as user 'Frank' (admin). If you need it run as
'postgres', let me know. Copied handle.exe into /tmp (i.e.,
C:\cygwin\tmp) so I could run within BASH shell. Also note I checked
the file permissions in /tmp, just to be sure all was as it should be
(all this was done, by the way, after once again removing CYGWIN=nontsec
environ var and rebooting, so it's as it was):
______________________________________________________________________
Frank(at)SEESINK /tmp
$ ./handle.exe -a -p ipc-daemon | fgrep Multi
d4: Semaphore \BaseNamedObjects\MultiSemCtl_
d8: Semaphore \BaseNamedObjects\MultiSemSem_
dc: Semaphore \BaseNamedObjects\MultiSemShm_
e0: Semaphore \BaseNamedObjects\MultiSemMsg_
e4: File C:\cygwin\tmp\MultiFileSem
ec: File C:\cygwin\tmp\MultiFileShm
f4: File C:\cygwin\tmp\MultiFileMsg

Frank(at)SEESINK /tmp
$ ls -al
total 4138
drwxrwxrwx+ 4 Frank Users 0 May 5 13:44 .
drwxrwx---+ 10 Frank Users 0 Apr 29 17:37 ..
-rw-rw-rw- 1 SYSTEM Administ 3916520 May 5 13:15 MultiFileMsg
-rw-rw-rw- 1 SYSTEM Administ 22032 May 5 13:15 MultiFileSem
-rw-rw-rw- 1 SYSTEM Administ 202768 May 5 13:15 MultiFileShm
-rwx------+ 1 Frank None 69632 Oct 16 2001 handle.exe
...
______________________________________________________________________

Quick note: Prior to rebooting, while CYGWIN=nontsec was still in
effect, I noticed that the /tmp/MultiFile* files were tagged as owned by
user 'Frank' as opposed to 'SYSTEM'. Group was set to 'Administ' in
both cases. I figured with nontsec, EVERYTHING just appears as being
owned by the currently logged in user. That's what I recall from older
Cygwin versions anyway (prior to ntsec being default). But thought I'd
mention it 'just in case.'

...
>>I can't think of any apps which would get in the way of this, but
>>then, I'm not 100% clear on how CygIPC is contacted.
>
>
> ipc-daemon is contacted by opening semaphores -- exactly how cit does
> it. If not, why would I ask you to run cit?

I guess I should have been more clear. As the idea of semaphores are
not inherent in NT as in Unix, I was referring more to the system calls
being made by apps in order to contact CygIPC itself.

I'm more used to TCP/IP interaction, where you bind to a TCP or UDP
port as a server, and a client contacts the server by IP and TCP/UDP
port number. However, semaphores are more an internal mechanism (like
BSD sockets).

Somehow when you compile cit.c, those OpenSemaphore() calls are able to
route thru the Windows NT system to CygIPC. Now I know Cygwin1.dll
plays a role in all this somewhere, but as I don't code down at that
level, I'm out of my depth. But somewhere along the way Cygwin1.dll is
a shimmy that gives NT a functionality that it doesn't have itself, and
as far as I know, DLLs are basically just libraries of functions.

But in the end,as far as NT is concerned, there are two
processes--CygIPC and the app that is trying to reach it
(ipctest/initdb/postgres/whatever). And yet those two processes need to
be able to interact with each other. That implies some pathway through
NT's internal messaging system. Whatever else happens, in the end you
have to use the underlying OS' IPC-like mechanisms, even if you're
building something like Cygwin.

Using TCP/IP speak, I was curious HOW, exactly, CygIPC sets itself to
'listen' and how apps like ipctest 'call' CygIPC. It's obviously NOT
via the TCP/IP stack, as postmaster in the end does when you use the
'-i' switch, otherwise I would be looking at things like port/address
blocking by firewalling software, etc. But these apps are using
whatever NT uses internally for IPC. I'm just wondering if somehow,
when CygIPC sets itself up to 'listen', it is restricted to contact by
'Frank' for some reason (though I can't imagine why that would be....by
users with 'Administrative' privileges I could see easier, but that
didn't work when I made 'postgres' a member, so...)

>>And as mentioned, I've tried running CygIPC AS user 'postgres', and
>>even that did not work.
>
>
> The above is truly amazing!

Tell me about it.

Jason Tishler wrote:
> Frank,
>
> On Fri, May 02, 2003 at 05:21:30PM -0400, Frank Seesink wrote:
>
>>(Note that unless otherwise noted, I am not logging off/on but just
>>fast user context switching between accounts to save time.)
>
>
> Until we get to the bottom of this, please do *not* do the above. In
> this way, we can at least remove one variable.

Alright...but man does that slow things down a bit. Closing down
email/news/etc, logging off, logging in under another user, firing up
apps to see what you want done, closing down, blah blah blah. I'll do
it, but I won't like it. :-)

Jason Tishler wrote:
> Frank,
>
> On Fri, May 02, 2003 at 06:11:06PM -0400, Frank Seesink wrote:
>
>>More info:
>>
>>* Reset everything to the way things 'normally' would be (user
>> 'postgres' only a member of 'Users', ipc-daemon configured to run as
>> Local System account, etc.).
>>[snip]
>>* Switched out and logged in as 'postgres', brought up BASH, and tried
>> 'ipctest s', and failed as usual.
>>* Did a 'ps' and saw only the shell and the ps command...no ipc-daemon.
>
>
> Did you do a "ps" or a "ps -ef"? With the former, ipc-daemon should not
> be displayed since it was running under a different user.

Always 'ps -ef', as shown in the printout in the previous email.

>>* For fun, tried 'ipc-daemon &', and it fired up!
>
>
> YA truly amazing occurrence. The above should have failed as follows:
>
> $ ipc-daemon
> (ipc-daemon) IPC-daemon is already started !!

I wonder what would happen if I tried firing it up manually from
'Frank'? Let me see if I get this error. Then I'll try running it
twice as 'postgres'. At this point, anything that might shed light on
things, even if ever so slightly. [I have to keep thinking of Thomas
Edison as I work on this. Every day I find 50 more things that DON'T
work. Eventually I hope to find the one that DOES. :-) Otherwise, it's
water tower/sniper rifle time...and that would probably put a crimp in
my career. :-) ]

>>It's as if the copy of ipc-daemon running in the 'postgres' context is
>>oblivious to the copy running as Local System account.
>
>
> Yes. I believe understanding the above will lead to the root cause of
> this problem.

Seems reasonable. By the way, I have tried undoing the steps I do to
'harden' NT boxes, but so far, to no avail.

Jason Tishler wrote:
...[snip]...

> I did some more Googling. Does the following apply to your setup?
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;264651
>
> If so, then try switching Terminal Services to Application Server mode.
> Does this have any affect?

Ok, coupla questions. I understand where you're coming from with the
link, but

1. It applies to Windows 2000 Server & Advanced Server only
[I'm running Windows XP Professional SP1]
2. The issue was apparently resolved in Win2K SP2 (which was
released more than a year ago...SP3 is the latest for Win2K
at this point).
3. Ummmm...how exactly does one switch 'Terminal Services' to
'Application Server' mode? For that matter, how do you see
what mode it's in? All I see is an NT service, like
any other (e.g., Cygwin IPC Daemon), and I don't notice
anything obvious in the Registry settings for that service
(HKLM\System\CCS\Services\TermService). This is normally a
DO NOT TOUCH type service. You leave it be, and let it do
its thing.

Frank Seesink wrote:
...
>>> * For fun, tried 'ipc-daemon &', and it fired up!
>>
>>
>>
>> YA truly amazing occurrence. The above should have failed as follows:
>>
>> $ ipc-daemon
>> (ipc-daemon) IPC-daemon is already started !!
>
>
> I wonder what would happen if I tried firing it up manually from
> 'Frank'? Let me see if I get this error. Then I'll try running it
> twice as 'postgres'. At this point, anything that might shed light on
> things, even if ever so slightly. [I have to keep thinking of Thomas

FYI: Running

$ ipc-daemon &

from user 'Frank' when CygIPC is already running (as an NT service
under the SYSTEM|Administ context) caused ipc-daemon to fire up and then
die almost immediately with a [Done] message. Original NT service is
still up and running. However, it does NOT show the message you list
above. Thought you should know.

Haven't tried it as 'postgres' yet.

Jason Tishler wrote:
> Frank,
>
> On Mon, May 05, 2003 at 08:13:01AM -0400, Jason Tishler wrote:
>
>>On Fri, May 02, 2003 at 06:11:06PM -0400, Frank Seesink wrote:
>>
>>>It's as if the copy of ipc-daemon running in the 'postgres' context
>>>is oblivious to the copy running as Local System account.
>>
>>Yes. I believe understanding the above will lead to the root cause of
>>this problem.
>
>
> I did some more Googling. Does the following apply to your setup?
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;264651

Jason,

After my last post regarding the above link, I switched over to the
'postgres' account and tried 'ipctest s' and it worked!!! GAAH! I
started feeling like Markko Paas (the thread that started on 16 Jan
2003) which culminated with him posting on 22 Jan 2003 that

..."ipctest s" started working "out of blue"

but I wanted to get to the bottom of this, once and for all. Then this
post of yours tickled my brain.

Turns out you da man! I think you may have found the culprit! You
see, I had LOGGED OUT as 'Frank', then logged in as 'postgres'. To test
my theory, I logged out of 'postgres', logged back in as 'Frank', then
switched ([WindowKey]-L) out and logged in as 'postgres'. Sure enough,
'ipctest s' failed!

I have now tested further by logging back in as 'Frank' (needed admin
rights) and doing

$ net stop ipc-daemon
$ rm /tmp/MultiFile*

then rebooting (ipc-daemon is set as a service to start
'Automatically'), logged in as 'postgres', and ran 'ipctest s'. It worked!

Darn it all to heck, that stupid Windows Terminal Services issue is
STILL there!!! Now, I have no clue how you switch it from 'Remote
Administration' mode to 'Application Server' mode. But I believe the
very act of using the Fast User Switching (where you 'Switch Users'
without logging out) is what is causing this.

I have tried this several times now, and it consistently points to the
fact that if you run ipctest when you have another account logged in
(and that's IT no less...no need to be running any Cywgin apps, the BASH
shell, whatnot), ipctest fails. I have no clue whether this would also
apply if someone used the VPN server feature in XP Pro and up, but note
that the 'Fast User Switch Compatibility' NT service (as well as others)
all rely on the 'Terminal Services' NT service, so what you may be
looking at here is a cascading effect: any action/service that relies
on 'Terminal Services' may trigger this gotcha.

For a final test, I am going to blow away the entire Cygwin
distribution install, clean house on the Registry, etc., and start anew.
I will then install Cygwin as I always have done, and simply avoid
doing any user context switching. If I have any difficulties, I suspect
they may be with the default file permissions of the /tmp and /usr/bin
directories. I will simply do the steps as outlined in the PostgreSQL
README for starters, however, and once done, I'll let you know what
steps are required beyond the basic install (like possibly 'chmod 777
/tmp' and 'chmod 755 /usr/bin /usr/bin/*').

This information may come in handy for others trying to install/run
PostgreSQL on Cywgin under Windows XP.

Again, thanks for the diligence in this, Jason. I'll try to
reciprocate the favor now in what little way I can (though may not post
'til morning depending how long it takes me). I want to know this for
my own sake as much as for helping others. I don't want to see
PostgreSQL stop 'out of the blue' any more than the next guy. :-)

----- Original Message -----
From: "Frank Seesink" <frank(at)mail(dot)wvnet(dot)edu>
To: <pgsql-cygwin(at)postgresql(dot)org>
Sent: Monday, May 05, 2003 8:36 PM
Subject: Re: [CYGWIN] initdb failure with PostgreSQL 7.3.2 / Cygwin 1.3.22-1
/

> Jason Tishler wrote:
> > Frank,
> >
> > On Mon, May 05, 2003 at 08:13:01AM -0400, Jason Tishler wrote:
> >
> >>On Fri, May 02, 2003 at 06:11:06PM -0400, Frank Seesink wrote:
> >>
> >>>It's as if the copy of ipc-daemon running in the 'postgres' context
> >>>is oblivious to the copy running as Local System account.
> >>
> >>Yes. I believe understanding the above will lead to the root cause of
> >>this problem.
> >
> >
> > I did some more Googling. Does the following apply to your setup?
> >
> > http://support.microsoft.com/default.aspx?scid=kb;en-us;264651
>
> Jason,
>
> After my last post regarding the above link, I switched over to the
> 'postgres' account and tried 'ipctest s' and it worked!!! GAAH! I
> started feeling like Markko Paas (the thread that started on 16 Jan
> 2003) which culminated with him posting on 22 Jan 2003 that
>
> ..."ipctest s" started working "out of blue"
>
> but I wanted to get to the bottom of this, once and for all. Then this
> post of yours tickled my brain.
>
> Turns out you da man! I think you may have found the culprit! You
> see, I had LOGGED OUT as 'Frank', then logged in as 'postgres'. To test
> my theory, I logged out of 'postgres', logged back in as 'Frank', then
> switched ([WindowKey]-L) out and logged in as 'postgres'. Sure enough,
> 'ipctest s' failed!
>
> I have now tested further by logging back in as 'Frank' (needed admin
> rights) and doing
>
> $ net stop ipc-daemon
> $ rm /tmp/MultiFile*
>
> then rebooting (ipc-daemon is set as a service to start
> 'Automatically'), logged in as 'postgres', and ran 'ipctest s'. It
worked!
>
> Darn it all to heck, that stupid Windows Terminal Services issue is
> STILL there!!! Now, I have no clue how you switch it from 'Remote
> Administration' mode to 'Application Server' mode. But I believe the
> very act of using the Fast User Switching (where you 'Switch Users'
> without logging out) is what is causing this.
>
> I have tried this several times now, and it consistently points to the
> fact that if you run ipctest when you have another account logged in
> (and that's IT no less...no need to be running any Cywgin apps, the BASH
> shell, whatnot), ipctest fails. I have no clue whether this would also
> apply if someone used the VPN server feature in XP Pro and up, but note
> that the 'Fast User Switch Compatibility' NT service (as well as others)
> all rely on the 'Terminal Services' NT service, so what you may be
> looking at here is a cascading effect: any action/service that relies
> on 'Terminal Services' may trigger this gotcha.
>
> For a final test, I am going to blow away the entire Cygwin
> distribution install, clean house on the Registry, etc., and start anew.
> I will then install Cygwin as I always have done, and simply avoid
> doing any user context switching. If I have any difficulties, I suspect
> they may be with the default file permissions of the /tmp and /usr/bin
> directories. I will simply do the steps as outlined in the PostgreSQL
> README for starters, however, and once done, I'll let you know what
> steps are required beyond the basic install (like possibly 'chmod 777
> /tmp' and 'chmod 755 /usr/bin /usr/bin/*').
>
> This information may come in handy for others trying to install/run
> PostgreSQL on Cywgin under Windows XP.

I'd really appreciate clearer indication when to log in as myself
(administrator), and when to log in as Postgres.

> Again, thanks for the diligence in this, Jason. I'll try to
> reciprocate the favor now in what little way I can (though may not post
> 'til morning depending how long it takes me). I want to know this for
> my own sake as much as for helping others. I don't want to see
> PostgreSQL stop 'out of the blue' any more than the next guy. :-)
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

On Mon, May 05, 2003 at 03:36:56PM -0400, Frank Seesink wrote:
> Turns out you da man! I think you may have found the culprit! You
> see, I had LOGGED OUT as 'Frank', then logged in as 'postgres'. To test
> my theory, I logged out of 'postgres', logged back in as 'Frank', then
> switched ([WindowKey]-L) out and logged in as 'postgres'. Sure enough,
> 'ipctest s' failed!

On Win-NT it's possible to use the Cygwin ssh to login as 'postgres'
in a shell window while continuing to run as your normal account
elsewhere, avoiding the disruption of tearing everything down to log
off and back on again. That ssh approach might work well in your
context too, but I've never tried it in XP.

--
Fred Yankowski fred(at)ontosys(dot)com tel: +1.630.879.1312
OntoSys, Inc PGP keyID: 7B449345 fax: +1.630.879.1370
www.ontosys.com 38W242 Deerpath Rd, Batavia, IL 60510-9461, USA

Fred,

On Mon, May 05, 2003 at 04:35:09PM -0500, Fred Yankowski wrote:
> On Win-NT it's possible to use the Cygwin ssh to login as 'postgres'
> in a shell window while continuing to run as your normal account
> elsewhere, avoiding the disruption of tearing everything down to log
> off and back on again. That ssh approach might work well in your
> context too, but I've never tried it in XP.

It works under XP (Pro) too.

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Frank,

On Mon, May 05, 2003 at 03:36:56PM -0400, Frank Seesink wrote:
> Jason Tishler wrote:
> >[snip]
> >I did some more Googling. Does the following apply to your setup?
> >
> > http://support.microsoft.com/default.aspx?scid=kb;en-us;264651
>
> [snip]
> But I believe the very act of using the Fast User Switching (where you
> 'Switch Users' without logging out) is what is causing this.

I have confirmed the above hypothesis with the attached test program,
cit2.c. If cit2.exe is invoked as follows:

$ cit2
192 = OpenSemaphore(MultiSemSem_) succeeded

then it will work only under Terminal Services session 0 (i.e., the
first user to log on).

However, if cit2.exe is invoked as follows:

$ cit2 1
192 = OpenSemaphore(Global\MultiSemSem_) succeeded

then it will work under any Terminal Services session (i.e, even after a
Fast User Switch).

See the following MSDN article:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/termserv/termserv/kernel_object_namespaces.asp

which explains the multiple Terminal Services namespaces and how to
access them.

I will work with the cygipc maintainer to enhance cygipc to properly
handle Fast User Switching.

Your help in debugging this problem is greatly appreciated.

Thanks,
Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Jason Tishler wrote:
...
> I have confirmed the above hypothesis with the attached test program,
> cit2.c. If cit2.exe is invoked as follows:
...
> I will work with the cygipc maintainer to enhance cygipc to properly
> handle Fast User Switching.
>
> Your help in debugging this problem is greatly appreciated.

Jason,

Thanks for all the help in this. As I promised, I did a completely
clean install of Cygwin to verify this, and yep, the issue is definitely
with the 'Switch User' "feature" in XP. As long as users completey sign
off as one user before signing on as another, they should be ok. Might
be worth a comment in the README, at least 'til it's dealt with.

Now, coupla pointers for those doing clean installs of Cygwin v1.3.22-1
with PostgreSQL v7.3.2. The README instructions are fine as is.
However, note that for whatever reason, the current Cygwin install
(Cygwin v1.3.22-1 and setup.exe v2.340.2.5) appears to set /tmp and
/usr/bin permissions incorrectly. So basically, users who are doing
such an install may want to be sure to
______________________________________________________________________
1. Install Cygwin as usual.
2. Run BASH and type the commands

$ chmod 777 /tmp
$ chmod 755 /usr/bin /usr/bin/*

to be sure the directories/files have the right permissions.

3. Install CygIPC as per its instructions. Not sure, but might be worth
copying a few of those instructions over to the PostgreSQL README,
as the actual command for unzipping and untarring the file is not on
the page referenced by the usual URL:

http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/index.html

but rather at

http://www.neuro.gatech.edu/users/cwilson/cygutils/how_to_install.html

4. Follow the instructions in /usr/doc/Cygwin/postgresql-7.3.2.README
______________________________________________________________________

WARNING: One issue I still found is that when a user reaches step #10
in the README, they may get the following:
____________________________________________________________
$ psql -U postgres template1
psql: could not connect to server: Bad file descriptor
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
____________________________________________________________

Looking in /tmp, I found the following:
______________________________________________________________________
$ ls -al
total 5512
drwxrwxrwx+ 3 Frank Users 0 May 6 13:41 .
drwxrwx---+ 10 Frank Users 0 May 5 19:04 ..
-rwx------ 1 postgres None 51 May 6 13:41 .s.PGSQL.5432
-rw------- 1 postgres None 32 May 6 13:41 .s.PGSQL.5432.lock
-rw-rw-rw- 1 SYSTEM Administ 3916520 May 6 13:41 MultiFileMsg
-rw-rw-rw- 1 SYSTEM Administ 22032 May 6 13:41 MultiFileSem
-rw-rw-rw- 1 SYSTEM Administ 202768 May 6 13:41 MultiFileShm
-rw------- 1 postgres None 1499136 May 6 13:41 cygipc_0
______________________________________________________________________

Notice the permissions on the files

.s.PGSQL.5432
.s.PGSQL.5432.lock

are such that ONLY the owner can access them. As these files are used
for internal socket communications between psql and postmaster, and step
#10 shows the user being logged in with the administrative account (NOT
the 'postgres' account that owns those files), psql will fail, as it is
unable to read/write to these files at all.

A simple

$ chmod 755 /tmp/.s.PGSQL*

will correct this...but ONLY for the current bootup. If the user
installed PostgreSQL and CygIPC as NT services, upon reboot, postmaster
will regenerate these /tmp/ files with the permissions reset to ONLY
allow the owner 'postgres' access. THIS is a problem.

[Jason, do you know how PostgreSQL determines these permissions, or is
this yet another weird chmod issue? I don't recall this failing with
older versions. Does the fact that user SYSTEM in /etc/passwd not have
a path to a shell have any effect on setting permissions, as this is the
user context under which 'postmaster' runs? I haven't been able to
figure out how to get postmaster to fire up and have the permissions on
these temp files set to something that gives users other than 'postgres'
enough access so that psql via internal sockets works properly.]

Oh, and if users figure this isn't a problem as they'll only access
PostgreSQL via the TCP/IP port (5432 by default), and so they simply
follow the above instructions and then try the command:

$ psql -h localhost -U postgres template1

this will also likely fail, as users must first modify the file

/usr/share/postgresql/data/postgresql.conf

to permit TCP/IP connections (disabled by default). To do so, note that

/usr/share/postgresql/data

has its permissions set so only user 'postgres' can access the files (a
reasonable security setup). So simply log off as the admin user and log
back in as 'postgres', work your way down to /usr/share/postgresql/data,
and use 'pico', 'vi', or the editor of your choice to modify
postgresql.conf so that it contains

tcpip_socket = true

(it's one of the first settings in the file).

Another option: Do this as step #8.1 (after initializing the database)
while still logged in as 'postgres'.

Once the /tmp/.s.PGSQL* permission issue is resolved, and Cygwin itself
sets permissions on /tmp and /usr/bin properly, hopefully the added
steps won't be necessary. But for those so inclined, note whatever
issues occur, if you understand how the pieces interact, then you'll
have better luck tracking the problem down. And in the case of
PostgreSQL, the pieces I know to watch are

* the executables (located in /usr/bin)
* the data and configuration files
(located in /usr/share/postgresql/data normally)
* the CygIPC semaphore files (in /tmp)
* and the PostgreSQL lock files (also in /tmp)

Hope this information is helpful to at least one other person.

Frank,

On Tue, May 06, 2003 at 02:42:11PM -0400, Frank Seesink wrote:
> 4. Follow the instructions in /usr/doc/Cygwin/postgresql-7.3.2.README
> ______________________________________________________________________
>
> WARNING: One issue I still found is that when a user reaches step #10
> in the README, they may get the following:
> ____________________________________________________________
> $ psql -U postgres template1
> psql: could not connect to server: Bad file descriptor
> Is the server running locally and accepting
> connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
> ____________________________________________________________

The above is fixed in Cygwin CVS:

http://archives.postgresql.org/pgsql-cygwin/2003-03/msg00053.php

and the Cygwin snapshots:

http://cygwin.com/snapshots/

Just download the latest cygwin1-YYYYMMDD.dll.bz2, bunzip2 it, and
replace cygwin1.dll with cygwin1-YYYYMMDD.dll (when *all* Cygwin process
are stopped).

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Jason Tishler wrote:
> Frank,
>
> On Tue, May 06, 2003 at 02:42:11PM -0400, Frank Seesink wrote:
>
>>4. Follow the instructions in /usr/doc/Cygwin/postgresql-7.3.2.README
>>______________________________________________________________________
>>
>>WARNING: One issue I still found is that when a user reaches step #10
>> in the README, they may get the following:
>> ____________________________________________________________
>> $ psql -U postgres template1
>> psql: could not connect to server: Bad file descriptor
>> Is the server running locally and accepting
>> connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
>> ____________________________________________________________
>
>
> The above is fixed in Cygwin CVS:
>
> http://archives.postgresql.org/pgsql-cygwin/2003-03/msg00053.php
>
> and the Cygwin snapshots:
>
> http://cygwin.com/snapshots/
>
> Just download the latest cygwin1-YYYYMMDD.dll.bz2, bunzip2 it, and
> replace cygwin1.dll with cygwin1-YYYYMMDD.dll (when *all* Cygwin process
> are stopped).

Thanks, Jason. Will do.

Oh, and over lunch I realized one faux pax in what I wrote.
'postmaster' runs not under the SYSTEM user context, but 'postgres'.
Duh. My bad.

[Jason,

Hope this is ok to post. Just figured I'd try to help others avoid the
issues I ran into.]

For anyone newcomers just getting started with PostgreSQL running under
Cygwin and Windows, here is a general set of instructions that should
help you avoid some 'gotchas' during your install.

______________________________________________________________________
SOFTWARE VERSIONS

These instructions were written when the software was at the following
versions:

Cygwin setup.exe v2.340.2.5
Cygwin v1.3.22-1
CygIPC v1.13.2-1
PostgreSQL v7.3.2 (as packaged in Cygwin distribution)

Items marked with '***' indicate a workaround until bugs can be fixed in
Windows, in Cygwin, or whereever the bug is hiding.
______________________________________________________________________
CAVEATS/WARNINGS/NOTICES/BASIC INFO

A. WARNING!!!! If you are running Windows XP, DO NOT USE the
'Switch User' feature to jump between accounts. This is KEY! ***
Instead, completely log off as one user before logging on as
another.
[This is due to a bug in the 'Terminal Services' NT service. For
details, look through postings on this list.]

B. Cygwin does not 'hook' itself into Windows in any serious ways.
It basically does 3 things:

* creates a folder on your HD (typically C:\cygwin)
* Creates shortcuts on your desktop and/or Start menu
(see [Start] | All Programs | Cygwin)
* Adds a few keys to the Windows Registry
* HKCU\Software\Cygnus Solutions
* HKLM\Software\Cygnus Solutions

This means that at any time, if you are truly unhappy with the
Cygwin install, to "start fresh", simply shut down any Cygwin
related processes (e.g., the BASH shell and anything like PostgreSQL
or CygIPC) so that no files are locked, and then delete the items
above. Voila! Your system is like new.

C. In its default configuration, you can think of Cygwin as Unix
running in a 'sandbox' as it were on your Windows PC. That is,
Cygwin stays within it's C:\cygwin directory tree and does not
stray. Any time you are asked to download a .tar/.gz/.bz file
and install it somehow in Cygwin, use whatever you normally would
use to download the file(s) in question, and just be sure to drop
them somewhere within C:\cygwin so that Cygwin can "see" the
file(s). For example, you might save the files to C:\cygwin\tmp,
then run the BASH shell and do

$ cd /tmp

to get to your new found file(s). Also note that any time you are
working with .tar/.gz/.bz files (any compressed file) that are meant
for use in Cygwin, it is best to use the tools that are within
Cygwin itself. This helps avoid the various issues of people using
Windows tools like WinZip and so forth to decompress files.

Think "Cygwin files are touched only by Cygwin tools."

D. CygIPC is such a .tar.bz2 file, so only work with it within Cywgin.

E. In MS Windows, you get used to files being in certain locations.
Programs tend to install their files in 'C:\Program Files'. The
Windows OS files themselves tend to be in 'C:\Windows' (or C:\WinNT
for those running Windows NT4 or 2000).

Just like Windows, Unix systems have places where you typically find
files. Cygwin, being a form of Unix if you will, follows this
model. For simplicity's sake, just note the following comparison:

MS Windows Unix/Cygwin
----------------------- -----------------------
Root of files C:\ /
Program files C:\Program Files /bin
/usr/bin
/usr/local/bin
Temp files C:\Windows\Temp /tmp
Program data C:\Documents & Settings /usr

This is NOT a complete picture, but will give you enough to start
playing.

F. PostgreSQL is a robust piece of software, and it was originally
written for Unix. Like any software, the more you understand it,
the better off you'll be. For now, just note the following:

* PostgreSQL's executable programs (e.g., postmaster, psql,
etc.) can be found in
/bin
/usr/bin
* PostgreSQL's database files and configuration files are stored
by default in
/usr/share/postgresql/data
* PostgreSQL's socket files (which provide a way for you to hook
into the database engine 'postmaster' from 'psql' etc.) are
found in
/tmp

G. For CygIPC, upon which PostgreSQL currently depends, note the
fowllowing:
* CygIPC's executable programs (e.g., ipc-daemon) can be found
in
/usr/local/bin
* CygIPC's semaphore files (which it uses to maintain data) can
be found in
/tmp

H. If you have difficulty in getting PostgreSQL to work, note that
often things can be traced to something related to 'permissions' and
whether one piece of software is allowed access to a file or another
piece of software based on who is asking for what.

With all this rattling in your brain, let's get started.
______________________________________________________________________
STEPS TO INSTALL AND RUN POSTGRESQL UNDER CYGWIN

__________________________________________________________________
1. Log into Windows as a user with Administrative Rights.

__________________________________________________________________
2. Note where you will be installing Cygwin. Normally this is
C:\cygwin
default, but if different, make note of it. For the duration,
these instructions assume you used the default.

__________________________________________________________________
3. Add 'C:\cygwin\bin' to the system PATH environment variable.
* Click on the [Start] button
* RIGHT-click on 'My Computer'
* Choose 'Properties' from the popup menu
* Click the 'Advanced' tab
* Click the [Environment Variables' button.
* Under 'System Variables', scroll down and double-click on
'Path' to bring up a dialog box.
* Carefully edit the 'Variable value:' field and add an entry
for C:\Cygwin\bin. I recommend adding it after the Windows
system paths. For example, it might read as

C:\WINDOWS\system32;C:\WINDOWS;C:\Cygwin\bin;...
^^^^^^^^^^^^^^
NOTE: If you screw up, click [Cancel] to go back, then
start again.
* Click [Ok] to save your changes, and keep clicking [Ok] to
close out of all dialog boxes and windows.

__________________________________________________________________
4. Install Cygwin as usual.
This instruction is purposefully vague, as there are many ways in
which Cygwin could be installed. Most folks simply visit

http://www.cygwin.com

and run the setup.exe file directly from the site. If you do this,
setup.exe guides you through the process, though you may wish to
read up on Cygwin itself on the website first.

__________________________________________________________________
5. Once Cygwin has finished installing, run the Cygwin BASH Shell
(normally an icon is created on the Desktop or under
[Start] | All Programs | Cygwin) and type the following commands
(the $ is the prompt...do not type this):

$ chmod 777 /tmp
$ chmod 755 /usr/bin /usr/bin/*

This ensures that the directories/files have the right permissions
for what we are doing. ***

__________________________________________________________________
6. At this point, we needed the latest CVS snapshot version of
cygwin1.dll. ***
There appears to be a bug in the current release which causes
trouble when you want to run the client 'psql' program to hook into
'postmaster' on the same computer. NOTE: If you only connect to
PostgreSQL via TCP/IP connections, you may skip this step.

* Download the latest CVS snapshot build by visiting

http://cygwin.com/snapshots/

and clicking on the latest cygwin1-YYYYMMDD.dll.bz2 file,
makin sure to save it within the Cygwin tree.
These instructions assume a file called
'cygwin1-20030504.dll.bz2' and that it is stored in /tmp
(i.e., C:\cygwin\tmp).
* Run the Cygwin BASH Shell and enter the following commands:

$ cd /tmp
$ bunzip2 cygwin1-20030504.dll.bz2

* Exit the BASH shell and make sure no other Cygwin programs
are running.
* From Windows itself, using whatever mechanism you are
comfortable with, drill down to
C:\cygwin\bin
* Locate the file 'cygwin1.dll' and rename it 'cygwin1.dll.old'.
* Now navigate to
C:\cygwin\tmp
and rename 'cygwin1-20030504.dll.bz2' to 'cygwin1.dll'
* Copy the file 'cygwin1.dll' in C:\cygwin\tmp over to
C:\cygwin\bin
* You have now effectively updated your cygwin1.dll file to an
updated version that should work.

__________________________________________________________________
7. Install CygIPC as per its instructions.
Basically, visit this link to download CygIPC v1.13.2-1:

http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/cygipc-1.13-2.tar.bz2

Make sure to save the file somewhere within Cygwin's space. These
instructions assume you saved the file in C:\Cygwin\tmp.

Now run the Cygwin BASH Shell and type the following commands:

$ cd /
$ bunzip2 -c /tmp/cygipc-1.13-2.tar.bz2 | tar xvf -

This should decompress CygIPC to the right locations.

For reference, note the CygIPC page is listed at

http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/index.html

and the instructions they provide for installing CygIPC are at

http://www.neuro.gatech.edu/users/cwilson/cygutils/how_to_install.html

__________________________________________________________________
8. At this point, you are ready to follow the instructions written by
Jason Tishler, which can be found either in the Cygwin file located
at /usr/doc/Cygwin/postgresql-7.3.2.README
(i.e., C:\cygwin\usr\doc\Cygwin\postgresql-7.3.2.README)
or online at

http://www.tishler.net/jason/software/postgresql/postgresql-7.3.2.README

Note that when you reach Step #10 in the README file, if you wish to
access the PostgreSQL database engine internally (using sockets),
you must have done step #6 above (at least until the official
Cygwin1.dll is updated).

If you have no intention of accessing PostgreSQL internally, but
rather intend, like many people, to access the database via TCP/IP
connections, then also note you must add a step to the instructions
in the README, basically editing the files

/usr/share/postgresql/data/postgresql.conf
/usr/share/postgresql/data/pg_hba.conf

'postgresql.conf' controls whether TCP/IP connections are allowed at
all, and 'pg_hba.conf' specifies who is allowed to connect to what.

In the following steps, it is assumed you will use the PICO editor
within the Cygwin BASH shell to edit the file above. However,
you could also edit this file from Windows using an editor that
does not mangle the file (Do NOT use Windows NotePad). For example,
you could go to [Start] | All Programs | Accessories | WordPad, then
click File | Open... and navigate to

C:\cygwin\usr\share\postgresql\data\postgresql.conf
C:\cygwin\usr\share\postgresql\data\pg_hba.conf

and edit the files as indicated below. Your choice.

______________________________________________________________
Step #8.1: Setup PostgreSQL to allow TCP/IP connections.

* Run Cygwin BASH Shell and type the commands:

$ cd /usr/share/postgresql/data
$ pico postgresql.conf

* Hit [PageDown] until you see
______________________________________________________
...
#
# Connection Parameters
#
#tcpip_socket = false
#ssl = false
....
______________________________________________________

and change the tcpip_socket line to
______________________________________________________
...
#
# Connection Parameters
#
tcpip_socket = true
#ssl = false
....
______________________________________________________

* Now hit [CTRL]-[X], then [Y], then [Enter] to save
the file. You have now enabled TCP/IP connections.
* Next open the pg_hba.conf file using the commands:

$ cd /usr/share/postgresql/data
$ pico pg_hba.conf

read the file and understand what it is telling you, then
make adjustments accordingly. By default this file will
allow anyone on 'localhost' (the same PC that PostgreSQL is
running on) to connect. However, if you are running software
such as pgAdmin II, EMS PostgreSQL Manager, PG Explorer, or
any of the other such utilities from a DIFFERENT PC than the
the one installed Cygwin/PostgreSQL onto, you must modify
this file to permit your client PC access.
______________________________________________________________

______________________________________________________________________
FINAL COMMENTS

For those wishing to access the PostgreSQL engine (postmaster) via
TCP/IP, note the psql command changes slightly. Whereas locally you
would type something like

$ psql -U postgres template1

for a TCP/IP connection, you would type

$ psql -h localhost -U postgres template1

This assumes the default PostgreSQL TCP/IP port (5432). For more
detailed instructions, type

$ psql --help

for more information.

Also note that this message, like Cygwin and PostgreSQL, is a work in
progress. I just wanted to get something out there that might help
those who are looking for the steps necessary and were having trouble
similar to myself. Hope this helps.

[UPDATE: Corrected slight error on my part in step #5 below.
Apologies in advance. chmod commands should only have added
settings, not necessarily modified existing ones.]

For anyone newcomers just getting started with PostgreSQL running under
Cygwin and Windows, here is a general set of instructions that should
help you avoid some 'gotchas' during your install.

______________________________________________________________________
SOFTWARE VERSIONS

These instructions were written when the software was at the following
versions:

Cygwin setup.exe v2.340.2.5
Cygwin v1.3.22-1
CygIPC v1.13.2-1
PostgreSQL v7.3.2 (as packaged in Cygwin distribution)

Items marked with '***' indicate a workaround until bugs can be fixed in
Windows, in Cygwin, or whereever the bug is hiding.
______________________________________________________________________
CAVEATS/WARNINGS/NOTICES/BASIC INFO

A. WARNING!!!! If you are running Windows XP, DO NOT USE the
'Switch User' feature to jump between accounts. This is KEY! ***
Instead, completely log off as one user before logging on as
another.
[This is due to a bug in the 'Terminal Services' NT service. For
details, look through postings on this list.]

B. Cygwin does not 'hook' itself into Windows in any serious ways.
It basically does 3 things:

* creates a folder on your HD (typically C:\cygwin)
* Creates shortcuts on your desktop and/or Start menu
(see [Start] | All Programs | Cygwin)
* Adds a few keys to the Windows Registry
* HKCU\Software\Cygnus Solutions
* HKLM\Software\Cygnus Solutions

This means that at any time, if you are truly unhappy with the
Cygwin install, to "start fresh", simply shut down any Cygwin
related processes (e.g., the BASH shell and anything like PostgreSQL
or CygIPC) so that no files are locked, and then delete the items
above. Voila! Your system is like new.

C. In its default configuration, you can think of Cygwin as Unix
running in a 'sandbox' as it were on your Windows PC. That is,
Cygwin stays within it's C:\cygwin directory tree and does not
stray. Any time you are asked to download a .tar/.gz/.bz file
and install it somehow in Cygwin, use whatever you normally would
use to download the file(s) in question, and just be sure to drop
them somewhere within C:\cygwin so that Cygwin can "see" the
file(s). For example, you might save the files to C:\cygwin\tmp,
then run the BASH shell and do

$ cd /tmp

to get to your new found file(s). Also note that any time you are
working with .tar/.gz/.bz files (any compressed file) that are meant
for use in Cygwin, it is best to use the tools that are within
Cygwin itself. This helps avoid the various issues of people using
Windows tools like WinZip and so forth to decompress files.

Think "Cygwin files are touched only by Cygwin tools."

D. CygIPC is such a .tar.bz2 file, so only work with it within Cywgin.

E. In MS Windows, you get used to files being in certain locations.
Programs tend to install their files in 'C:\Program Files'. The
Windows OS files themselves tend to be in 'C:\Windows' (or C:\WinNT
for those running Windows NT4 or 2000).

Just like Windows, Unix systems have places where you typically find
files. Cygwin, being a form of Unix if you will, follows this
model. For simplicity's sake, just note the following comparison:

MS Windows Unix/Cygwin
----------------------- -----------------------
Root of files C:\ /
Program files C:\Program Files /bin
/usr/bin
/usr/local/bin
Temp files C:\Windows\Temp /tmp
Program data C:\Documents & Settings /usr

This is NOT a complete picture, but will give you enough to start
playing.

F. PostgreSQL is a robust piece of software, and it was originally
written for Unix. Like any software, the more you understand it,
the better off you'll be. For now, just note the following:

* PostgreSQL's executable programs (e.g., postmaster, psql,
etc.) can be found in
/bin
/usr/bin
* PostgreSQL's database files and configuration files are stored
by default in
/usr/share/postgresql/data
* PostgreSQL's socket files (which provide a way for you to hook
into the database engine 'postmaster' from 'psql' etc.) are
found in
/tmp

G. For CygIPC, upon which PostgreSQL currently depends, note the
fowllowing:
* CygIPC's executable programs (e.g., ipc-daemon) can be found
in
/usr/local/bin
* CygIPC's semaphore files (which it uses to maintain data) can
be found in
/tmp

H. If you have difficulty in getting PostgreSQL to work, note that
often things can be traced to something related to 'permissions' and
whether one piece of software is allowed access to a file or another
piece of software based on who is asking for what.

With all this rattling in your brain, let's get started.
______________________________________________________________________
STEPS TO INSTALL AND RUN POSTGRESQL UNDER CYGWIN

__________________________________________________________________
1. Log into Windows as a user with Administrative Rights.

__________________________________________________________________
2. Note where you will be installing Cygwin. Normally this is
C:\cygwin
default, but if different, make note of it. For the duration,
these instructions assume you used the default.

__________________________________________________________________
3. Add 'C:\cygwin\bin' to the system PATH environment variable.
* Click on the [Start] button
* RIGHT-click on 'My Computer'
* Choose 'Properties' from the popup menu
* Click the 'Advanced' tab
* Click the [Environment Variables' button.
* Under 'System Variables', scroll down and double-click on
'Path' to bring up a dialog box.
* Carefully edit the 'Variable value:' field and add an entry
for C:\Cygwin\bin. I recommend adding it after the Windows
system paths. For example, it might read as

C:\WINDOWS\system32;C:\WINDOWS;C:\Cygwin\bin;...
^^^^^^^^^^^^^^
NOTE: If you screw up, click [Cancel] to go back, then
start again.
* Click [Ok] to save your changes, and keep clicking [Ok] to
close out of all dialog boxes and windows.

__________________________________________________________________
4. Install Cygwin as usual.
This instruction is purposefully vague, as there are many ways in
which Cygwin could be installed. Most folks simply visit

http://www.cygwin.com

and run the setup.exe file directly from the site. If you do this,
setup.exe guides you through the process, though you may wish to
read up on Cygwin itself on the website first.

__________________________________________________________________
5. Once Cygwin has finished installing, run the Cygwin BASH Shell
(normally an icon is created on the Desktop or under
[Start] | All Programs | Cygwin) and type the following commands
(the $ is the prompt...do not type this):

$ chmod 777 /tmp
$ chmod a+rw /usr/bin /usr/bin/*

This ensures that the directories/files have the right permissions
for what we are doing. /tmp has full access by everyone, and we
have added read/write access for all to the /usr/bin directory so
you can execute programs regardless of what account you are logged
in with. ***

__________________________________________________________________
6. At this point, we needed the latest CVS snapshot version of
cygwin1.dll. ***
There appears to be a bug in the current release which causes
trouble when you want to run the client 'psql' program to hook into
'postmaster' on the same computer. NOTE: If you only connect to
PostgreSQL via TCP/IP connections, you may skip this step.

* Download the latest CVS snapshot build by visiting

http://cygwin.com/snapshots/

and clicking on the latest cygwin1-YYYYMMDD.dll.bz2 file,
makin sure to save it within the Cygwin tree.
These instructions assume a file called
'cygwin1-20030504.dll.bz2' and that it is stored in /tmp
(i.e., C:\cygwin\tmp).
* Run the Cygwin BASH Shell and enter the following commands:

$ cd /tmp
$ bunzip2 cygwin1-20030504.dll.bz2

* Exit the BASH shell and make sure no other Cygwin programs
are running.
* From Windows itself, using whatever mechanism you are
comfortable with, drill down to
C:\cygwin\bin
* Locate the file 'cygwin1.dll' and rename it 'cygwin1.dll.old'.
* Now navigate to
C:\cygwin\tmp
and rename 'cygwin1-20030504.dll.bz2' to 'cygwin1.dll'
* Copy the file 'cygwin1.dll' in C:\cygwin\tmp over to
C:\cygwin\bin
* You have now effectively updated your cygwin1.dll file to an
updated version that should work.

__________________________________________________________________
7. Install CygIPC as per its instructions.
Basically, visit this link to download CygIPC v1.13.2-1:

http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/cygipc-1.13-2.tar.bz2

Make sure to save the file somewhere within Cygwin's space. These
instructions assume you saved the file in C:\Cygwin\tmp.

Now run the Cygwin BASH Shell and type the following commands:

$ cd /
$ bunzip2 -c /tmp/cygipc-1.13-2.tar.bz2 | tar xvf -

This should decompress CygIPC to the right locations.

For reference, note the CygIPC page is listed at

http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/index.html

and the instructions they provide for installing CygIPC are at

http://www.neuro.gatech.edu/users/cwilson/cygutils/how_to_install.html

__________________________________________________________________
8. At this point, you are ready to follow the instructions written by
Jason Tishler, which can be found either in the Cygwin file located
at /usr/doc/Cygwin/postgresql-7.3.2.README
(i.e., C:\cygwin\usr\doc\Cygwin\postgresql-7.3.2.README)
or online at

http://www.tishler.net/jason/software/postgresql/postgresql-7.3.2.README

Note that when you reach Step #10 in the README file, if you wish to
access the PostgreSQL database engine internally (using sockets),
you must have done step #6 above (at least until the official
Cygwin1.dll is updated).

If you have no intention of accessing PostgreSQL internally, but
rather intend, like many people, to access the database via TCP/IP
connections, then also note you must add a step to the instructions
in the README, basically editing the files

/usr/share/postgresql/data/postgresql.conf
/usr/share/postgresql/data/pg_hba.conf

'postgresql.conf' controls whether TCP/IP connections are allowed at
all, and 'pg_hba.conf' specifies who is allowed to connect to what.

In the following steps, it is assumed you will use the PICO editor
within the Cygwin BASH shell to edit the file above. However,
you could also edit this file from Windows using an editor that
does not mangle the file (Do NOT use Windows NotePad). For example,
you could go to [Start] | All Programs | Accessories | WordPad, then
click File | Open... and navigate to

C:\cygwin\usr\share\postgresql\data\postgresql.conf
C:\cygwin\usr\share\postgresql\data\pg_hba.conf

and edit the files as indicated below. Your choice.

______________________________________________________________
Step #8.1: Setup PostgreSQL to allow TCP/IP connections.

* Run Cygwin BASH Shell and type the commands:

$ cd /usr/share/postgresql/data
$ pico postgresql.conf

* Hit [PageDown] until you see
______________________________________________________
...
#
# Connection Parameters
#
#tcpip_socket = false
#ssl = false
....
______________________________________________________

and change the tcpip_socket line to
______________________________________________________
...
#
# Connection Parameters
#
tcpip_socket = true
#ssl = false
....
______________________________________________________

* Now hit [CTRL]-[X], then [Y], then [Enter] to save
the file. You have now enabled TCP/IP connections.
* Next open the pg_hba.conf file using the commands:

$ cd /usr/share/postgresql/data
$ pico pg_hba.conf

read the file and understand what it is telling you, then
make adjustments accordingly. By default this file will
allow anyone on 'localhost' (the same PC that PostgreSQL is
running on) to connect. However, if you are running software
such as pgAdmin II, EMS PostgreSQL Manager, PG Explorer, or
any of the other such utilities from a DIFFERENT PC than the
the one installed Cygwin/PostgreSQL onto, you must modify
this file to permit your client PC access.
______________________________________________________________

______________________________________________________________________
FINAL COMMENTS

For those wishing to access the PostgreSQL engine (postmaster) via
TCP/IP, note the psql command changes slightly. Whereas locally you
would type something like

$ psql -U postgres template1

for a TCP/IP connection, you would type

$ psql -h localhost -U postgres template1

This assumes the default PostgreSQL TCP/IP port (5432). For more
detailed instructions, type

$ psql --help

for more information.

Also note that this message, like Cygwin and PostgreSQL, is a work in
progress. I just wanted to get something out there that might help
those who are looking for the steps necessary and were having trouble
similar to myself. Hope this helps.

[UPDATE 2: Yep, screwed up again. I'm the world's biggest idiot.
Corrected slight error on my part in step #5 below...again.
Apologies in advance. chmod commands need to allow all to
execute...not write. Also added a few more caveats to
uninstalling Cygwin.]

For anyone newcomers just getting started with PostgreSQL running under
Cygwin and Windows, here is a general set of instructions that should
help you avoid some 'gotchas' during your install.

______________________________________________________________________
SOFTWARE VERSIONS

These instructions were written when the software was at the following
versions:

Cygwin setup.exe v2.340.2.5
Cygwin v1.3.22-1
CygIPC v1.13.2-1
PostgreSQL v7.3.2 (as packaged in Cygwin distribution)

Items marked with '***' indicate a workaround until bugs can be fixed in
Windows, in Cygwin, or whereever the bug is hiding.
______________________________________________________________________
CAVEATS/WARNINGS/NOTICES/BASIC INFO

A. WARNING!!!! If you are running Windows XP, DO NOT USE the
'Switch User' feature to jump between accounts. This is KEY! ***
Instead, completely log off as one user before logging on as
another.
[This is due to a bug in the 'Terminal Services' NT service. For
details, look through postings on this list.]

B. Cygwin does not 'hook' itself into Windows in any serious ways.
It basically does 3 things:

* creates a folder on your HD (typically C:\cygwin)
* Creates shortcuts on your desktop and/or Start menu
(see [Start] | All Programs | Cygwin)
* Adds a few keys to the Windows Registry
* HKCU\Software\Cygnus Solutions
* HKLM\Software\Cygnus Solutions

This means that at any time, if you are truly unhappy with the
Cygwin install, to "start fresh", simply shut down any Cygwin
related processes (e.g., the BASH shell and anything like PostgreSQL
or CygIPC) so that no files are locked, and then delete the items
above. Voila! Your system is like new.

One warning, though: You may find when you go to delete the
Cygwin files in C:\cygwin that Windows tells you that files are
in use. This can be due to NOT shutting down some Cygwin app you
had running, OR it is possible that it is due to the way file
permissions are set on some folder within the C:\cygwin tree.
In the latter case, first try logging off the account completely
to see if some app you were using didn't "let go" of a file.
Second, be sure to be sitting at the console, as I have found
programs like pcAnywhere seem to goof a bit and (in the latest
case) sometimes keep files open in the weirdest places (like
an X11 font file!). Finally, if all else fails, override the
permissions on the entire C:\cygwin tree, being sure to give
yourself full rights to that folder and have it propogate those
rights down the entire tree. One of the above should free things
up so you can delete.

C. In its default configuration, you can think of Cygwin as Unix
running in a 'sandbox' as it were on your Windows PC. That is,
Cygwin stays within it's C:\cygwin directory tree and does not
stray. Any time you are asked to download a .tar/.gz/.bz file
and install it somehow in Cygwin, use whatever you normally would
use to download the file(s) in question, and just be sure to drop
them somewhere within C:\cygwin so that Cygwin can "see" the
file(s). For example, you might save the files to C:\cygwin\tmp,
then run the BASH shell and do

$ cd /tmp

to get to your new found file(s). Also note that any time you are
working with .tar/.gz/.bz files (any compressed file) that are meant
for use in Cygwin, it is best to use the tools that are within
Cygwin itself. This helps avoid the various issues of people using
Windows tools like WinZip and so forth to decompress files.

Think "Cygwin files are touched only by Cygwin tools."

D. CygIPC is such a .tar.bz2 file, so only work with it within Cywgin.

E. In MS Windows, you get used to files being in certain locations.
Programs tend to install their files in 'C:\Program Files'. The
Windows OS files themselves tend to be in 'C:\Windows' (or C:\WinNT
for those running Windows NT4 or 2000).

Just like Windows, Unix systems have places where you typically find
files. Cygwin, being a form of Unix if you will, follows this
model. For simplicity's sake, just note the following comparison:

MS Windows Unix/Cygwin
----------------------- -----------------------
Root of files C:\ /
Program files C:\Program Files /bin
/usr/bin
/usr/local/bin
Temp files C:\Windows\Temp /tmp
Program data C:\Documents & Settings /usr

This is NOT a complete picture, but will give you enough to start
playing.

F. PostgreSQL is a robust piece of software, and it was originally
written for Unix. Like any software, the more you understand it,
the better off you'll be. For now, just note the following:

* PostgreSQL's executable programs (e.g., postmaster, psql,
etc.) can be found in
/bin
/usr/bin
* PostgreSQL's database files and configuration files are stored
by default in
/usr/share/postgresql/data
* PostgreSQL's socket files (which provide a way for you to hook
into the database engine 'postmaster' from 'psql' etc.) are
found in
/tmp

G. For CygIPC, upon which PostgreSQL currently depends, note the
fowllowing:
* CygIPC's executable programs (e.g., ipc-daemon) can be found
in
/usr/local/bin
* CygIPC's semaphore files (which it uses to maintain data) can
be found in
/tmp

H. If you have difficulty in getting PostgreSQL to work, note that
often things can be traced to something related to 'permissions' and
whether one piece of software is allowed access to a file or another
piece of software based on who is asking for what.

With all this rattling in your brain, let's get started.
______________________________________________________________________
STEPS TO INSTALL AND RUN POSTGRESQL UNDER CYGWIN

__________________________________________________________________
1. Log into Windows as a user with Administrative Rights.

__________________________________________________________________
2. Note where you will be installing Cygwin. Normally this is
C:\cygwin
default, but if different, make note of it. For the duration,
these instructions assume you used the default.

__________________________________________________________________
3. Add 'C:\cygwin\bin' to the system PATH environment variable.
* Click on the [Start] button
* RIGHT-click on 'My Computer'
* Choose 'Properties' from the popup menu
* Click the 'Advanced' tab
* Click the [Environment Variables' button.
* Under 'System Variables', scroll down and double-click on
'Path' to bring up a dialog box.
* Carefully edit the 'Variable value:' field and add an entry
for C:\Cygwin\bin. I recommend adding it after the Windows
system paths. For example, it might read as

C:\WINDOWS\system32;C:\WINDOWS;C:\Cygwin\bin;...
^^^^^^^^^^^^^^
NOTE: If you screw up, click [Cancel] to go back, then
start again.
* Click [Ok] to save your changes, and keep clicking [Ok] to
close out of all dialog boxes and windows.

__________________________________________________________________
4. Install Cygwin as usual.
This instruction is purposefully vague, as there are many ways in
which Cygwin could be installed. Most folks simply visit

http://www.cygwin.com

and run the setup.exe file directly from the site. If you do this,
setup.exe guides you through the process, though you may wish to
read up on Cygwin itself on the website first.

__________________________________________________________________
5. Once Cygwin has finished installing, run the Cygwin BASH Shell
(normally an icon is created on the Desktop or under
[Start] | All Programs | Cygwin) and type the following commands
(the $ is the prompt...do not type this):

$ chmod 777 /tmp
$ chmod a+rx /usr/bin /usr/bin/*

This ensures that the directories/files have the right permissions
for what we are doing. /tmp has full access by everyone, and we
have added read/write access for all to the /usr/bin directory so
you can execute programs regardless of what account you are logged
in with. ***

__________________________________________________________________
6. At this point, we needed the latest CVS snapshot version of
cygwin1.dll. ***
There appears to be a bug in the current release which causes
trouble when you want to run the client 'psql' program to hook into
'postmaster' on the same computer. NOTE: If you only connect to
PostgreSQL via TCP/IP connections, you may skip this step.

* Download the latest CVS snapshot build by visiting

http://cygwin.com/snapshots/

and clicking on the latest cygwin1-YYYYMMDD.dll.bz2 file,
makin sure to save it within the Cygwin tree.
These instructions assume a file called
'cygwin1-20030504.dll.bz2' and that it is stored in /tmp
(i.e., C:\cygwin\tmp).
* Run the Cygwin BASH Shell and enter the following commands:

$ cd /tmp
$ bunzip2 cygwin1-20030504.dll.bz2

* Exit the BASH shell and make sure no other Cygwin programs
are running.
* From Windows itself, using whatever mechanism you are
comfortable with, drill down to
C:\cygwin\bin
* Locate the file 'cygwin1.dll' and rename it 'cygwin1.dll.old'.
* Now navigate to
C:\cygwin\tmp
and rename 'cygwin1-20030504.dll.bz2' to 'cygwin1.dll'
* Copy the file 'cygwin1.dll' in C:\cygwin\tmp over to
C:\cygwin\bin
* You have now effectively updated your cygwin1.dll file to an
updated version that should work.

__________________________________________________________________
7. Install CygIPC as per its instructions.
Basically, visit this link to download CygIPC v1.13.2-1:

http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/cygipc-1.13-2.tar.bz2

Make sure to save the file somewhere within Cygwin's space. These
instructions assume you saved the file in C:\Cygwin\tmp.

Now run the Cygwin BASH Shell and type the following commands:

$ cd /
$ bunzip2 -c /tmp/cygipc-1.13-2.tar.bz2 | tar xvf -

This should decompress CygIPC to the right locations.

For reference, note the CygIPC page is listed at

http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/index.html

and the instructions they provide for installing CygIPC are at

http://www.neuro.gatech.edu/users/cwilson/cygutils/how_to_install.html

__________________________________________________________________
8. At this point, you are ready to follow the instructions written by
Jason Tishler, which can be found either in the Cygwin file located
at /usr/doc/Cygwin/postgresql-7.3.2.README
(i.e., C:\cygwin\usr\doc\Cygwin\postgresql-7.3.2.README)
or online at

http://www.tishler.net/jason/software/postgresql/postgresql-7.3.2.README

Note that when you reach Step #10 in the README file, if you wish to
access the PostgreSQL database engine internally (using sockets),
you must have done step #6 above (at least until the official
Cygwin1.dll is updated).

If you have no intention of accessing PostgreSQL internally, but
rather intend, like many people, to access the database via TCP/IP
connections, then also note you must add a step to the instructions
in the README, basically editing the files

/usr/share/postgresql/data/postgresql.conf
/usr/share/postgresql/data/pg_hba.conf

'postgresql.conf' controls whether TCP/IP connections are allowed at
all, and 'pg_hba.conf' specifies who is allowed to connect to what.

In the following steps, it is assumed you will use the PICO editor
within the Cygwin BASH shell to edit the file above. However,
you could also edit this file from Windows using an editor that
does not mangle the file (Do NOT use Windows NotePad). For example,
you could go to [Start] | All Programs | Accessories | WordPad, then
click File | Open... and navigate to

C:\cygwin\usr\share\postgresql\data\postgresql.conf
C:\cygwin\usr\share\postgresql\data\pg_hba.conf

and edit the files as indicated below. Your choice.

______________________________________________________________
Step #8.1: Setup PostgreSQL to allow TCP/IP connections.

* Run Cygwin BASH Shell and type the commands:

$ cd /usr/share/postgresql/data
$ pico postgresql.conf

* Hit [PageDown] until you see
______________________________________________________
...
#
# Connection Parameters
#
#tcpip_socket = false
#ssl = false
....
______________________________________________________

and change the tcpip_socket line to
______________________________________________________
...
#
# Connection Parameters
#
tcpip_socket = true
#ssl = false
....
______________________________________________________

* Now hit [CTRL]-[X], then [Y], then [Enter] to save
the file. You have now enabled TCP/IP connections.
* Next open the pg_hba.conf file using the commands:

$ cd /usr/share/postgresql/data
$ pico pg_hba.conf

read the file and understand what it is telling you, then
make adjustments accordingly. By default this file will
allow anyone on 'localhost' (the same PC that PostgreSQL is
running on) to connect. However, if you are running software
such as pgAdmin II, EMS PostgreSQL Manager, PG Explorer, or
any of the other such utilities from a DIFFERENT PC than the
the one installed Cygwin/PostgreSQL onto, you must modify
this file to permit your client PC access.
______________________________________________________________

______________________________________________________________________
FINAL COMMENTS

For those wishing to access the PostgreSQL engine (postmaster) via
TCP/IP, note the psql command changes slightly. Whereas locally you
would type something like

$ psql -U postgres template1

for a TCP/IP connection, you would type

$ psql -h localhost -U postgres template1

This assumes the default PostgreSQL TCP/IP port (5432). For more
detailed instructions, type

$ psql --help

for more information.

Also note that this message, like Cygwin and PostgreSQL, is a work in
progress. I just wanted to get something out there that might help
those who are looking for the steps necessary and were having trouble
similar to myself. Hope this helps.

Frank,

Sorry for the sluggish response time, but I was sidetracked by cygipc,
PostgreSQL, and ProFTPD patches yesterday.

On Tue, May 06, 2003 at 07:25:42PM -0400, Frank Seesink wrote:
> [Jason,
>
> Hope this is ok to post. Just figured I'd try to help others avoid
> the issues I ran into.]

No problem.

However, be careful, be *very* careful -- you are on a slippery slope.
First you write a README, then you submit a patch, and before you know
what happened, you have become a package maintainer. Believe me -- I
know! :,)

I have some comments on your write-up -- I will respond to your latest
version shortly...

Thanks,
Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Frank,

Thanks for the write-up -- it's great. I have just a few minor,
nitpicky comments below...

On Wed, May 07, 2003 at 12:35:19PM -0400, Frank Seesink wrote:
> A. WARNING!!!! If you are running Windows XP, DO NOT USE the
> 'Switch User' feature to jump between accounts. This is KEY! ***
> Instead, completely log off as one user before logging on as
> another.

A more convenient workaround is to set up sshd and use ssh to simulate
Unix's su:

$ ssh postgres(at)localhost # equivalent to "su postgres" on Unix

Note that the above will *not* trigger the XP Fast User Switching
problem.

> B. Cygwin does not 'hook' itself into Windows in any serious ways.
> It basically does 3 things:
>
> * creates a folder on your HD (typically C:\cygwin)
> * Creates shortcuts on your desktop and/or Start menu
> (see [Start] | All Programs | Cygwin)
> * Adds a few keys to the Windows Registry
> * HKCU\Software\Cygnus Solutions
> * HKLM\Software\Cygnus Solutions
>
> This means that at any time, if you are truly unhappy with the
> Cygwin install, to "start fresh", simply shut down any Cygwin
> related processes (e.g., the BASH shell and anything like PostgreSQL
> or CygIPC) so that no files are locked, and then delete the items
> above. Voila! Your system is like new.

One also needs to delete the program group and registry entries to
completely remove all traces of Cygwin.

> C. In its default configuration, you can think of Cygwin as Unix
> running in a 'sandbox' as it were on your Windows PC. That is,
> Cygwin stays within it's C:\cygwin directory tree and does not
> stray. Any time you are asked to download a .tar/.gz/.bz file
> and install it somehow in Cygwin, use whatever you normally would
> use to download the file(s) in question, and just be sure to drop
> them somewhere within C:\cygwin so that Cygwin can "see" the
> file(s).

Cygwin can "see" any file that Windows can. Just use /cygdrive/$X
(where $X is a drive letter such as a, c, d, etc.) to access files
which are not located under / (i.e., C:\Cygwin).

> 3. Add 'C:\cygwin\bin' to the system PATH environment variable.
> [snip]
> * Carefully edit the 'Variable value:' field and add an entry
> for C:\Cygwin\bin. I recommend adding it after the Windows
> system paths.

I recommend adding it before the Windows systems paths, but I'm a Cygwin
bigot. :,) Nevertheless, PostgreSQL will have problems finding sort,
find, etc. if the Cygwin path is added after instead of before.

> 7. Install CygIPC as per its instructions.
> [snip]
>
> Now run the Cygwin BASH Shell and type the following commands:
>
> $ cd /
> $ bunzip2 -c /tmp/cygipc-1.13-2.tar.bz2 | tar xvf -

I recommend the following instead:

$ tar -C / -xjf /tmp/cygipc-1.13-2.tar.bz2

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Jason Tishler wrote:
> Frank,
>
> Thanks for the write-up -- it's great. I have just a few minor,
> nitpicky comments below...
>
> On Wed, May 07, 2003 at 12:35:19PM -0400, Frank Seesink wrote:
>
>> A. WARNING!!!! If you are running Windows XP, DO NOT USE the
>> 'Switch User' feature to jump between accounts. This is KEY! ***
>> Instead, completely log off as one user before logging on as
>> another.
>
>
> A more convenient workaround is to set up sshd and use ssh to simulate
> Unix's su:
>
> $ ssh postgres(at)localhost # equivalent to "su postgres" on Unix
>
> Note that the above will *not* trigger the XP Fast User Switching
> problem.

Good point. I just wasn't sure how comfortable readers might be with
setting up more services like sshd, so I took the 'lazy' approach if you
will. :-) I would prefer an 'su' type setup myself though.

>> B. Cygwin does not 'hook' itself into Windows in any serious ways.
>> It basically does 3 things:
>>
>> * creates a folder on your HD (typically C:\cygwin)
>> * Creates shortcuts on your desktop and/or Start menu
>> (see [Start] | All Programs | Cygwin)
>> * Adds a few keys to the Windows Registry
>> * HKCU\Software\Cygnus Solutions
>> * HKLM\Software\Cygnus Solutions
>>
>> This means that at any time, if you are truly unhappy with the
>> Cygwin install, to "start fresh", simply shut down any Cygwin
>> related processes (e.g., the BASH shell and anything like PostgreSQL
>> or CygIPC) so that no files are locked, and then delete the items
>> above. Voila! Your system is like new.
>
>
> One also needs to delete the program group and registry entries to
> completely remove all traces of Cygwin.

Sorry. That's what I meant when I wrote "delete the items above", but
guess I could have worded it better. :-/

>> C. In its default configuration, you can think of Cygwin as Unix
>> running in a 'sandbox' as it were on your Windows PC. That is,
>> Cygwin stays within it's C:\cygwin directory tree and does not
>> stray. Any time you are asked to download a .tar/.gz/.bz file
>> and install it somehow in Cygwin, use whatever you normally would
>> use to download the file(s) in question, and just be sure to drop
>> them somewhere within C:\cygwin so that Cygwin can "see" the
>> file(s).
>
>
> Cygwin can "see" any file that Windows can. Just use /cygdrive/$X
> (where $X is a drive letter such as a, c, d, etc.) to access files
> which are not located under / (i.e., C:\Cygwin).

Yep, my bad. Never actually fully realized that, ya know? As I didn't
see 'cygdrive' at the root level in the BASH shell, didn't occur to me.
Always noticed it in the PATH within BASH though. Thanks. Learn
something new every day.

>> 3. Add 'C:\cygwin\bin' to the system PATH environment variable.
>> [snip]
>> * Carefully edit the 'Variable value:' field and add an entry
>> for C:\Cygwin\bin. I recommend adding it after the Windows
>> system paths.
>
>
> I recommend adding it before the Windows systems paths, but I'm a Cygwin
> bigot. :,) Nevertheless, PostgreSQL will have problems finding sort,
> find, etc. if the Cygwin path is added after instead of before.

Is this actually true? I wondered about this. I notice that if I look
at the environment table from a DOS shell, C:\cygwin\bin is listed after
the Windows system paths (the way I set it). However, if I run the BASH
shell, I see that Cygwin automatically puts its own paths first, before
tacking on the NT environment table version of PATH; e.g.,

From within BASH:
PATH='/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:...
{-----Cygwin bin paths-----} {Windows XP PATH...

The big question, I guess is, when 'postmaster' runs as an NT service,
does it run within the Cygwin 'shell' (giving it access to the 'sort'
and 'find' it expects), or does it run in the NT context, where it
suddenly accesses the NT utilities 'sort' and 'find'? [I honestly don't
know.]

Regardless, however, readers should note that whether they place
'C:\cygwin\bin' BEFORE or AFTER the Windows system paths, it will have
an effect either way. Specifically, I found these files in common
between 'C:\cygwin\bin' and 'C:\Windows\System32' (in WinXP Pro):

expand.exe
find.exe
ftp.exe
hostname.exe
lpr.exe
rcp.exe
rsh.exe
shutdown.exe
sort.exe
telnet.exe
tftp.exe

So for the moment, let's assume that 'postmaster' DOES rely on the
Windows PATH environment variable and does NOT run in the Cygwin
'shell'. Basically, for PostgreSQL users, the need to put C:\cygwin\bin
BEFORE the Windows system paths has consequences in that, while
necessary for 'sort' and 'find', this means that if you ever use any of
the above from a DOS shell, you'll end up using the Cygwin versions.

On the other hand, if you place 'C:\cygwin\bin' AFTER the Windows
system paths, you may have issues as noted by Jason; namely,
'postmaster' will find the WRONG 'sort' and 'find' (and the differences
between their functionality can be/is huge), with unknown consequences
(at least to me).

>> 7. Install CygIPC as per its instructions.
>> [snip]
>>
>> Now run the Cygwin BASH Shell and type the following commands:
>>
>> $ cd /
>> $ bunzip2 -c /tmp/cygipc-1.13-2.tar.bz2 | tar xvf -
>
>
> I recommend the following instead:
>
> $ tar -C / -xjf /tmp/cygipc-1.13-2.tar.bz2
>
> Jason
>

Frank,

On Fri, May 09, 2003 at 04:12:01PM -0400, Frank Seesink wrote:
> Jason Tishler wrote:
> >Cygwin can "see" any file that Windows can. Just use /cygdrive/$X
> >(where $X is a drive letter such as a, c, d, etc.) to access files
> >which are not located under / (i.e., C:\Cygwin).
>
> Yep, my bad. Never actually fully realized that, ya know? As I
> didn't see 'cygdrive' at the root level in the BASH shell, didn't
> occur to me. Always noticed it in the PATH within BASH though.
> Thanks. Learn something new every day.

I always create a /cygdrive (actually /mnt) on my Cygwin boxes so bash's
tab completion works on these kinds of paths too. Just another stupid
Cygwin trick... :,)

> >>3. Add 'C:\cygwin\bin' to the system PATH environment variable.
> >>[snip]
> >> * Carefully edit the 'Variable value:' field and add an entry
> >> for C:\Cygwin\bin. I recommend adding it after the Windows
> >> system paths.
> >
> >
> >I recommend adding it before the Windows systems paths, but I'm a
> >Cygwin bigot. :,) Nevertheless, PostgreSQL will have problems
> >finding sort, find, etc. if the Cygwin path is added after instead of
> >before.
>
> Is this actually true?

Yes, AFAICT.

> I notice that if I look at the environment table from a DOS shell,
> C:\cygwin\bin is listed after the Windows system paths (the way I set
> it). However, if I run the BASH shell, I see that Cygwin
> automatically puts its own paths first, before tacking on the NT
> environment table version of PATH; e.g.,
>
> From within BASH:
> PATH='/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:...

IIRC, Cygwin's /etc/profile does the above. Note that I use my own
/etc/profile that predates the Cygwin one so I'm not 100% sure. But,
what else would set PATH as such?

> The big question, I guess is, when 'postmaster' runs as an NT service,
> does it run within the Cygwin 'shell' (giving it access to the 'sort'
> and 'find' it expects),

No.

> or does it run in the NT context, where it suddenly accesses the NT
> utilities 'sort' and 'find'?

Kinda. It runs in the postgres context (or whatever user is assigned to
the postmaster service) which will use the PATH defined for that user.

However, you made me think of another option which may suit some users
better. Add the Cygwin bin directories to the end of the Windows system
PATH. But, use cygrunsrv's --env option when installing postmaster and
set postmaster's PATH so that the Cygwin bin directories are searched
first. In this way, one does not need to affect the Windows system PATH
or any user's PATH (including postgres) just to keep postmaster happy.

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Jason Tishler wrote:
[snip]
>>I notice that if I look at the environment table from a DOS shell,
>>C:\cygwin\bin is listed after the Windows system paths (the way I set
>>it). However, if I run the BASH shell, I see that Cygwin
>>automatically puts its own paths first, before tacking on the NT
>>environment table version of PATH; e.g.,
>>
>>From within BASH:
>>PATH='/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:...
>
>
> IIRC, Cygwin's /etc/profile does the above. Note that I use my own
> /etc/profile that predates the Cygwin one so I'm not 100% sure. But,
> what else would set PATH as such?
>
>
>>The big question, I guess is, when 'postmaster' runs as an NT service,
>>does it run within the Cygwin 'shell' (giving it access to the 'sort'
>>and 'find' it expects),
>
>
> No.
>
>
>>or does it run in the NT context, where it suddenly accesses the NT
>>utilities 'sort' and 'find'?
>
>
> Kinda. It runs in the postgres context (or whatever user is assigned to
> the postmaster service) which will use the PATH defined for that user.
>
> However, you made me think of another option which may suit some users
> better. Add the Cygwin bin directories to the end of the Windows system
> PATH. But, use cygrunsrv's --env option when installing postmaster and
> set postmaster's PATH so that the Cygwin bin directories are searched
> first. In this way, one does not need to affect the Windows system PATH
> or any user's PATH (including postgres) just to keep postmaster happy.

Just did 'cygrunsrv --help', and listed in there is the following:
______________________________________________________________________
...
-e, --env <VAR=VALUE> Optional environment strings which are added
to the environment when service is started.
You can add up to 255 environment strings
using the `--env' option.
Note: /bin is always added to $PATH to allow
all started applications to find at least
cygwin1.dll.
...
______________________________________________________________________

This seems to imply that this is automagically done by cygrunsrv. But
how do you make sure the Cygwin bin directories are searched FIRST? The
above section of help just says ".../bin is always added to $PATH...",
but doesn't state if at the end (which I would assume is the case) or
the beginning. And how could one tell?

Never mind. Just looked in /usr/doc/Cygwin/cygrunsrv.README, and it
contains the following info (emphasis mine):
______________________________________________________________________
...In the 'daemonize' mode, cygrunsrv sets up
the environment (according to flags set via the 'commandline'
mode). It adds '/bin' TO _THE FRONT_ of the PATH so that the
target service can find cygwin1.dll easily.
______________________________________________________________________

Further down is more info on how -env works:
______________________________________________________________________
...
-e, --env <VAR=value>
Optional environment strings which are added to the environment
when the service is started. You can add up to 255 environment strings
using multiple `--env' options. Note that '/bin:' is always appended
to the path to allow started applications to find cygwin1.dll. You
may also specify PATH=/a/path:/list if you like, but /bin WILL be
appended.

cygrunsrv -I foo -p /usr/bin/bar -e HOME=/e/services -e TMP=/var/tmp

A single level of quoting with either single (') or double (") quotes
is allowed:

cygrunsrv -I foo -p /usr/bin/bar -e BAR="\"/d/My Documents/services\""

results in an environment where BAR has the value
"/d/My Documents/services" *including the quotes* (the \-escaping and
the outer quotes are required to protect the command itself from bash).
If you don't understand this discussion about quoting, don't worry --
you probably don't need it.
______________________________________________________________________

So in short, your earlier post that C:\cygwin\bin needs to be placed in
front of the Windows system path may not be necessary after all...at
least for postmaster. And since a user running the 'psql' client under
Cygwin basically is doing so from a shell, IF (and I suspect this is NOT
the case) performing a sorted SELECT, for example, is handled by the
'psql' client, then all's well. But I'm guessing that postmaster does
the sorting (in the context of postmaster...hence Cygwin sort.exe takes
precedence over Win32 sort.exe). So problem solved. :-)

Your recommendation is more for those who always want Unix/Cygwin
functionality of functions like sort.exe, find.exe, and the others I
listed over the Win32 equivalents. Fair assessment?

Frank,

On Mon, May 12, 2003 at 01:22:03PM -0400, Frank Seesink wrote:
> Jason Tishler wrote:
> This seems to imply that this is automagically done by cygrunsrv. But
> how do you make sure the Cygwin bin directories are searched FIRST?
> The above section of help just says ".../bin is always added to
> $PATH...", but doesn't state if at the end (which I would assume is
> the case) or the beginning. And how could one tell?

Use the following procedure:

1. Install bash as a service via cygrunsrv.
2. Allow it to interact with the desktop.
3. Start the service.
4. Execute "echo $PATH" when it pops up.

> Never mind. Just looked in /usr/doc/Cygwin/cygrunsrv.README, and it
> contains the following info (emphasis mine):
> ______________________________________________________________________
> ...In the 'daemonize' mode, cygrunsrv sets up
> the environment (according to flags set via the 'commandline'
> mode). It adds '/bin' TO _THE FRONT_ of the PATH so that the
> target service can find cygwin1.dll easily.
> ______________________________________________________________________

If cygrunsrv prepends /bin then with should be OK.

> Further down is more info on how -env works:
> ______________________________________________________________________
> ...
> -e, --env <VAR=value>
> Optional environment strings which are added to the environment
> when the service is started. You can add up to 255 environment strings
> using multiple `--env' options. Note that '/bin:' is always appended
^^^^^^^^
> to the path to allow started applications to find cygwin1.dll. You
> may also specify PATH=/a/path:/list if you like, but /bin WILL be
> appended.
^^^^^^^^

However, the above seems to indicate that /bin is appended.

I guess that the above procedure may have to be used after all or the
source code consulted to resolve this issue....

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Jason Tishler wrote:
> Frank,
>
> On Mon, May 12, 2003 at 01:22:03PM -0400, Frank Seesink wrote:
>
>>Jason Tishler wrote:
>>This seems to imply that this is automagically done by cygrunsrv. But
>>how do you make sure the Cygwin bin directories are searched FIRST?
>>The above section of help just says ".../bin is always added to
>>$PATH...", but doesn't state if at the end (which I would assume is
>>the case) or the beginning. And how could one tell?
>
>
> Use the following procedure:
>
> 1. Install bash as a service via cygrunsrv.
> 2. Allow it to interact with the desktop.
> 3. Start the service.
> 4. Execute "echo $PATH" when it pops up.
...
> I guess that the above procedure may have to be used after all or the
> source code consulted to resolve this issue....

I have a feeling another means will be required. Though I'm relatively
sure that the Cygwin /bin directory is being prepended (and the 2nd
portion of help was just poorly worded), I thought I'd try the above
steps. Unfortunately, no go.

First, the "Allow service to interact with destkop" setting is only
available when the service is started under the Local System account.
However, the whole point of this test is to see what happens when
postmaster is run as user 'postgres'. Just the same, either way
(running as user 'postgres' or as Local System account) BASH fails to
start. The Event Logs are not very useful in telling you why, though.

So short of another means (possibly some kind of script--avoiding
desktop interaction--which saves the environment table to a file), not
sure how to tell other than looking at source.

I'll tinker and see if I can't get some positive feedback.

Frank,

On Tue, May 13, 2003 at 01:41:52PM -0400, Frank Seesink wrote:
> Jason Tishler wrote:
> >Use the following procedure:
> >
> > 1. Install bash as a service via cygrunsrv.
> > 2. Allow it to interact with the desktop.
> > 3. Start the service.
> > 4. Execute "echo $PATH" when it pops up.
>
> [snip]
>
> First, the "Allow service to interact with destkop" setting is only
> available when the service is started under the Local System account.

Oops, sorry for the misinformation. Shame on me -- I should have
checked again before writing the above.

> [snip]
>
> So short of another means (possibly some kind of script--avoiding
> desktop interaction--which saves the environment table to a file),
> not sure how to tell other than looking at source.

I just checked the source (cygrunsrv.cc:1076,1084):

char *env_path = getenv ("PATH");
if (!env_path)
setenv ("PATH", "/bin", 1);
else
{
char env_tmp[strlen (env_path) + 6];
***> strcat (strcpy (env_tmp, env_path), ":/bin"); <***
setenv ("PATH", env_tmp, 1);
}

Hence, "/bin" is appended not prepended.

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

This posting and its updates is an attempt to reduce the number of
questions asked regarding installing PostgreSQL under Cygwin and Windows
XP. It is NOT meant as a "Quick Start" guide, but more like a
"Long-winded, Detailed Approach for Those for Whom the Quick Start
Approach has Failed." New/changed information is marked with '&&&'.

Date: 14 May 2003

For anyone newcomers just getting started with PostgreSQL running
under Cygwin and Windows, here is a general set of instructions that
should help you avoid some 'gotchas' during your install.

______________________________________________________________________
SOFTWARE VERSIONS

These instructions were written when the software was at the
following versions:

Cygwin setup.exe v2.340.2.5
Cygwin v1.3.22-1
CygIPC v1.13.2-1
PostgreSQL v7.3.2 (as packaged in Cygwin distribution)

Items marked with '***' indicate a workaround until bugs can be fixed in
Windows, in Cygwin, or whereever the bug is hiding.
______________________________________________________________________
CAVEATS/WARNINGS/NOTICES/BASIC INFO

A. WARNING!!!! If you are running Windows XP, DO NOT USE the
'Switch User' feature to jump between accounts. This is KEY! ***
Instead, completely log off as one user before logging on as
another.
[This is due to a bug in the 'Terminal Services' NT service. For
details, look through postings on this list.]

&&& Another option is to set up sshd and use ssh to simulate Unix's su:

$ ssh postgres(at)localhost # equivalent to "su postgres" on Unix

Note that the above will *not* trigger the XP Fast User Switching
problem. However, it does require setting up the sshd service,
which is outside the scope of this posting. So depending on your
comfort level/experience with Cygwin/PostgreSQL, use the method
which works best for you.

B. Cygwin does not 'hook' itself into Windows in any serious ways.
It basically does 3 things:

* creates a folder on your HD (typically C:\cygwin)
* Creates shortcuts on your desktop and/or Start menu
(see [Start] | All Programs | Cygwin)
* Adds a few keys to the Windows Registry
* HKCU\Software\Cygnus Solutions
* HKLM\Software\Cygnus Solutions

This means that at any time, if you are truly unhappy with the
Cygwin install, to "start fresh", simply shut down any Cygwin
related processes (e.g., the BASH shell and anything like PostgreSQL
or CygIPC) so that no files are locked, and then delete the items
&&& above (C:\cygwin folder, shortcuts on Desktop and/or Start menu
including Program group 'Cygwin', and the registry keys mentioned).
Voila! Your system is like new.

One warning, though: You may find when you go to delete the
Cygwin files in C:\cygwin that Windows tells you that files are
in use. This can be due to NOT shutting down some Cygwin app you
had running, OR it is possible that it is due to the way file
permissions are set on some folder within the C:\cygwin tree.
In the latter case, first try logging off the account completely
to see if some app you were using didn't "let go" of a file.
Second, be sure to be sitting at the console, as I have found
programs like pcAnywhere seem to goof a bit and (in the latest
case) sometimes keep files open in the weirdest places (like
an X11 font file!). Finally, if all else fails, override the
permissions on the entire C:\cygwin tree, being sure to give
yourself full rights to that folder and have it propogate those
rights down the entire tree. One of the above should free things
up so you can delete.

C. In its default configuration, you can think of Cygwin as Unix
running in a 'sandbox' as it were on your Windows PC. That is,
Cygwin stays within it's C:\cygwin directory tree and does not
stray. Any time you are asked to download a .tar/.gz/.bz file
and install it somehow in Cygwin, use whatever you normally would
use to download the file(s) in question, and just be sure to drop
them somewhere within C:\cygwin so that Cygwin can "see" the
file(s). For example, you might save the files to C:\cygwin\tmp,
then run the BASH shell and do

$ cd /tmp

to get to your new found file(s). Also note that any time you are
working with .tar/.gz/.bz files (any compressed file) that are meant
for use in Cygwin, it is best to use the tools that are within
Cygwin itself. This helps avoid the various issues of people using
Windows tools like WinZip and so forth to decompress files.

Think "Cygwin files are touched only by Cygwin tools."

D. CygIPC is such a .tar.bz2 file, so only work with it within Cywgin.

E. In MS Windows, you get used to files being in certain locations.
Programs tend to install their files in 'C:\Program Files'. The
Windows OS files themselves tend to be in 'C:\Windows' (or C:\WinNT
for those running Windows NT4 or 2000).

Just like Windows, Unix systems have places where you typically find
files. Cygwin, being a form of Unix if you will, follows this
model. For simplicity's sake, just note the following comparison:

MS Windows Unix/Cygwin
----------------------- -----------------------
Root of files C:\ /
Program files C:\Program Files /bin
/usr/bin
/usr/local/bin
Temp files C:\Windows\Temp /tmp
Program data C:\Documents & Settings /usr

This is NOT a complete picture, but will give you enough to start
playing.

F. PostgreSQL is a robust piece of software, and it was originally
written for Unix. Like any software, the more you understand it,
the better off you'll be. For now, just note the following:

* PostgreSQL's executable programs (e.g., postmaster, psql,
etc.) can be found in
/bin
/usr/bin
* PostgreSQL's database files and configuration files are stored
by default in
/usr/share/postgresql/data
* PostgreSQL's socket files (which provide a way for you to hook
into the database engine 'postmaster' from 'psql' etc.) are
found in
/tmp

G. For CygIPC, upon which PostgreSQL currently depends, note the
fowllowing:
* CygIPC's executable programs (e.g., ipc-daemon) can be found
in
/usr/local/bin
* CygIPC's semaphore files (which it uses to maintain data) can
be found in
/tmp

H. If you have difficulty in getting PostgreSQL to work, note that
often things can be traced to something related to 'permissions' and
whether one piece of software is allowed access to a file or another
piece of software based on who is asking for what.

With all this rattling in your brain, let's get started.
______________________________________________________________________
STEPS TO INSTALL AND RUN POSTGRESQL UNDER CYGWIN

__________________________________________________________________
1. Log into Windows as a user with Administrative Rights.

__________________________________________________________________
2. Note where you will be installing Cygwin. Normally this is
C:\cygwin
default, but if different, make note of it. For the duration,
these instructions assume you used the default.

__________________________________________________________________
3. Add 'C:\cygwin\bin' to the system PATH environment variable.
* Click on the [Start] button
* RIGHT-click on 'My Computer'
* Choose 'Properties' from the popup menu
* Click the 'Advanced' tab
* Click the [Environment Variables' button.
* Under 'System Variables', scroll down and double-click on
'Path' to bring up a dialog box.
&&& * Carefully edit the 'Variable value:' field and add an entry
for C:\Cygwin\bin. I recommend adding it BEFORE the Windows
system paths for reasons explained below.
For example, it might read as

C:\Cygwin\bin;C:\WINDOWS\system32;C:\WINDOWS;...
^^^^^^^^^^^^^^
NOTE: If you screw up, click [Cancel] to go back, then
start again.

[The reason for placing Cygwin BEFORE the Windows directory is
to make sure PostgreSQL can find the right utilities that it
needs. For example, PostgreSQL relies on 'sort' and 'find',
who common Unix utilities. However, Windows ALSO offers
'sort' and 'find' commands. However, they behave differently.
In short, note whether you place Cygwin's path before or after
the Windows system paths, it has the potential to impact your
user experience. If you do not spend much time at the Windows
Command Prompt, odds are you won't notice the difference if
Cygwin is placed before the Windows system paths. But if you
use the above Windows utilities, note you'll find the Cygwin
versions work differently.]

* Click [Ok] to save your changes, and keep clicking [Ok] to
close out of all dialog boxes and windows.

__________________________________________________________________
4. Install Cygwin as usual.
This instruction is purposefully vague, as there are many ways in
which Cygwin could be installed. Most folks simply visit

http://www.cygwin.com

and run the setup.exe file directly from the site. If you do this,
setup.exe guides you through the process, though you may wish to
read up on Cygwin itself on the website first.

__________________________________________________________________
5. Once Cygwin has finished installing, run the Cygwin BASH Shell
(normally an icon is created on the Desktop or under
[Start] | All Programs | Cygwin) and type the following commands
(the $ is the prompt...do not type this):

$ chmod 777 /tmp
$ chmod a+rx /usr/bin /usr/bin/*

This ensures that the directories/files have the right permissions
for what we are doing. /tmp has full access by everyone, and we
have added read/write access for all to the /usr/bin directory so
you can execute programs regardless of what account you are logged
in with. ***

__________________________________________________________________
6. At this point, we needed the latest CVS snapshot version of
cygwin1.dll. ***
There appears to be a bug in the current release which causes
trouble when you want to run the client 'psql' program to hook into
'postmaster' on the same computer. NOTE: If you only connect to
PostgreSQL via TCP/IP connections, you may skip this step.

* Download the latest CVS snapshot build by visiting

http://cygwin.com/snapshots/

and clicking on the latest cygwin1-YYYYMMDD.dll.bz2 file,
makin sure to save it within the Cygwin tree.
These instructions assume a file called
'cygwin1-20030504.dll.bz2' and that it is stored in /tmp
(i.e., C:\cygwin\tmp).
* Run the Cygwin BASH Shell and enter the following commands:

$ cd /tmp
$ bunzip2 cygwin1-20030504.dll.bz2

* Exit the BASH shell and make sure no other Cygwin programs
are running.
* From Windows itself, using whatever mechanism you are
comfortable with, drill down to
C:\cygwin\bin
* Locate the file 'cygwin1.dll' and rename it 'cygwin1.dll.old'.
* Now navigate to
C:\cygwin\tmp
and rename 'cygwin1-20030504.dll.bz2' to 'cygwin1.dll'
* Copy the file 'cygwin1.dll' in C:\cygwin\tmp over to
C:\cygwin\bin
* You have now effectively updated your cygwin1.dll file to an
updated version that should work.

__________________________________________________________________
7. Install CygIPC as per its instructions.
Basically, visit this link to download CygIPC v1.13.2-1:

http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/cygipc-1.13-2.tar.bz2

Make sure to save the file somewhere within Cygwin's space. These
instructions assume you saved the file in C:\Cygwin\tmp.

Now run the Cygwin BASH Shell and type the following commands:

$ cd /
$ bunzip2 -c /tmp/cygipc-1.13-2.tar.bz2 | tar xvf -

This should decompress CygIPC to the right locations.

For reference, note the CygIPC page is listed at

http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/index.html

and the instructions they provide for installing CygIPC are at

http://www.neuro.gatech.edu/users/cwilson/cygutils/how_to_install.html

__________________________________________________________________
8. At this point, you are ready to follow the instructions written by
Jason Tishler, which can be found either in the Cygwin file located
at /usr/doc/Cygwin/postgresql-7.3.2.README
(i.e., C:\cygwin\usr\doc\Cygwin\postgresql-7.3.2.README)
or online at

http://www.tishler.net/jason/software/postgresql/postgresql-7.3.2.README

Note that when you reach Step #10 in the README file, if you wish to
access the PostgreSQL database engine internally (using sockets),
you must have done step #6 above (at least until the official
Cygwin1.dll is updated).

If you have no intention of accessing PostgreSQL internally, but
rather intend, like many people, to access the database via TCP/IP
connections, then also note you must add a step to the instructions
in the README, basically editing the files

/usr/share/postgresql/data/postgresql.conf
/usr/share/postgresql/data/pg_hba.conf

'postgresql.conf' controls whether TCP/IP connections are allowed at
all, and 'pg_hba.conf' specifies who is allowed to connect to what.

In the following steps, it is assumed you will use the PICO editor
within the Cygwin BASH shell to edit the file above. However,
you could also edit this file from Windows using an editor that
does not mangle the file (Do NOT use Windows NotePad). For example,
you could go to [Start] | All Programs | Accessories | WordPad, then
click File | Open... and navigate to

C:\cygwin\usr\share\postgresql\data\postgresql.conf
C:\cygwin\usr\share\postgresql\data\pg_hba.conf

and edit the files as indicated below. Your choice.

______________________________________________________________
Step #8.1: Setup PostgreSQL to allow TCP/IP connections.

* Run Cygwin BASH Shell and type the commands:

$ cd /usr/share/postgresql/data
$ pico postgresql.conf

* Hit [PageDown] until you see
______________________________________________________
...
#
# Connection Parameters
#
#tcpip_socket = false
#ssl = false
....
______________________________________________________

and change the tcpip_socket line to
______________________________________________________
...
#
# Connection Parameters
#
tcpip_socket = true
#ssl = false
....
______________________________________________________

* Now hit [CTRL]-[X], then [Y], then [Enter] to save
the file. You have now enabled TCP/IP connections.
* Next open the pg_hba.conf file using the commands:

$ cd /usr/share/postgresql/data
$ pico pg_hba.conf

read the file and understand what it is telling you, then
make adjustments accordingly. By default this file will
allow anyone on 'localhost' (the same PC that PostgreSQL is
running on) to connect. However, if you are running software
such as pgAdmin II, EMS PostgreSQL Manager, PG Explorer, or
any of the other such utilities from a DIFFERENT PC than the
the one installed Cygwin/PostgreSQL onto, you must modify
this file to permit your client PC access.
______________________________________________________________

&&&
9. At this point, you should be good to go. However, please note
the following. PostgreSQL, like many Unix services, uses a PID
(Process ID) file. Specifically, when 'postmaster' is run, it
it creates a file

/usr/share/postgresql/data/postmaster.pid

which contains the process ID that identifies the server
process. And when 'postmaster' shuts down, it deletes this PID
file...in theory.

The idea, in most cases, is that this allows you to scripts
for various purposes (e.g., shutting down 'postmaster'),
where you simply access this postmaster.pid file to obtain the
process id, compared to having to do a command like 'ps -ef'
and pipe the output to 'grep' or a file, where you then have to
search for the process id.

The challenge is that sometimes the PID file is NOT deleted.
This is a problem, as 'postmaster' will fail to start if the
postmaster.pid file already exists when you start up the
service. For example, in the NT service configuration
assumed here, it seems fair that you will want your PostgreSQL
engine to shutdown cleanly when Windows XP is told to shutdown
or restart, and that PostgreSQL will start up cleanly on the
next (re)boot.

Unfortunately, I often find that, for whatever reason, the
postmaster.pid file is left behind on reboot, and this is a
problem. If, on rebooting your Windows XP box, you find
PostgreSQL is no longer running, either check your Windows
Application Event Log (though this tends not to provide much
detail beyond the fact PostgreSQL failed to start) or look at
the PostgreSQL log file for details.

To check the Windows Application Event Log:

* Click on the [Start] button
* RIGHT-click on 'My Computer'
* Choose 'Manage' from the popup menu
* Look in
Computer Management (Local)
[-] System Tools
[-] Event Viewer
| +--- Application

To check the PostgreSQL log file:

* Run Cygwin BASH Shell and type the command:

$ more /var/log/postmaster.log

The solution to this is simply to manually DELETE the PID
file and then start 'postmaster'. However, if your intention
is to have a production level PostgreSQL server, this is
hardly sufficient. As one possible alternative, you may wish
to simply delete any such PID file when you restart your PC.
One way to do this is to modify the /etc/rc.d/rc.sysinit file
(which already is set to delete the PostgreSQL socket files in
/tmp) as follows (note the 'chmod' commands are used to make
sure Cygwin is able to delete the files:

* Run Cygwin BASH Shell and type the commands:

$ cd /etc/rc.d
$ pico rc.sysinit

* Hit [PageDown] until you see
______________________________________________________
...
# Delete Postgres sockets
rm -f /tmp/.s.PGSQL.*
....
______________________________________________________

and change it to the following:
______________________________________________________
...
# Delete Postgres sockets
chmod 777 /tmp/.s.PGSQL.*
rm -f /tmp/.s.PGSQL.*

# Delete Postgres PID file
chmod 777 /usr/share/postgresql/data/postmaster.pid
rm -f /usr/share/postgresql/data/postmaster.pid
...
______________________________________________________

* Now hit [CTRL]-[X], then [Y], then [Enter] to save
the file. You have now configured Cygwin to delete the
postmaster.pid file at each bootup.

Please note this is not a silver bullet however. There may
still be times when you find that PostgreSQL has not started,
and more often than not, it is due to a lingering postmaster.pid
file. If this is the case, you may need to seek other methods
(e.g., .BATch files, etc.) to make sure the PID file is deleted
on Windows startup. Just be sure whatever method you choose that
you have deleted the PID file BEFORE the 'postmaster' service
attempts to start. Other possibilities include, but are not
limited to, using software like KIXtart (www.kixtart.org) or
FireDaemon (www.firedaemon.com). I leave that to your
imagination. This is just to make you aware that this PID file
can be a pain the tush if it exists on startup.

______________________________________________________________________
FINAL COMMENTS

For those wishing to access the PostgreSQL engine (postmaster) via
TCP/IP, note the psql command changes slightly. Whereas locally you
would type something like

$ psql -U postgres template1

for a TCP/IP connection, you would type

$ psql -h localhost -U postgres template1

This assumes the default PostgreSQL TCP/IP port (5432). For more
detailed instructions, type

$ psql --help

for more information.

Also note that this message, like Cygwin and PostgreSQL, is a work
in progress. I just wanted to get something out there that might help
those who are looking for the steps necessary and were having trouble
similar to myself. Hope this helps.

Frank,

On Wed, May 14, 2003 at 06:28:46PM -0400, Frank Seesink wrote:
> This posting and its updates is an attempt to reduce the number of
> questions asked regarding installing PostgreSQL under Cygwin and
> Windows XP. It is NOT meant as a "Quick Start" guide, but more like a
> "Long-winded, Detailed Approach for Those for Whom the Quick Start
> Approach has Failed." New/changed information is marked with '&&&'.

Thanks for your README. You have done a great job which will be very
useful to the Cygwin PostgreSQL community.

> For example, PostgreSQL relies on 'sort' and 'find', who common
> Unix utilities.

Note that PostgreSQL appears to only rely on sort:

http://www.postgresql.org/docs/faqs/text/FAQ_MSWIN

I only mentioned find in a previous post to give an example of another
command affected by PATH.

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6