Re: initdb failure with PostgreSQL 7.3.2 / Cygwin 1.3.22-1 / - Mailing list pgsql-cygwin
From | Frank Seesink |
---|---|
Subject | Re: initdb failure with PostgreSQL 7.3.2 / Cygwin 1.3.22-1 / |
Date | |
Msg-id | b8u645$129$1@main.gmane.org Whole thread Raw |
In response to | Re: initdb failure with PostgreSQL 7.3.2 / Cygwin 1.3.22-1 / (Jason Tishler <jason@tishler.net>) |
Responses |
Re: initdb failure with PostgreSQL 7.3.2 / Cygwin 1.3.22-1 /
|
List | pgsql-cygwin |
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.
pgsql-cygwin by date: