Обсуждение: psql 7.2 AND 7.1.3 failing on Cygwin 1.3.9 pgsql 7.2 install, and createlang
psql 7.2 AND 7.1.3 failing on Cygwin 1.3.9 pgsql 7.2 install, and createlang
От
"Tim Finch, FosterFinch Ltd"
Дата:
### PSQL I noticed a thread a few weeks ago about psql in 7.2 in cygwin doing a segmentation dump. I have the same problem. I followed the thread that said the 7.1.3 psql build does not do the dump. It does on mine, giving the same dump. I have the postmaster 7.2.2 installed as a service and working fine with pgAdmin II 1.2.0 (well as far as I can tell). I did have 7.1.3 installed in Cygwin before putting on 7.2.2 7.1.3 psql gives this stackdump text file, seemingly the same error then that psql 7.2.2 gives??? I am not a C or 'internals of Unix' programmer but have a pretty good grasp of generally whats going on, but obviously am at a dead end myself now. If anyone can offer help that would be great. Thanks in advance. Exception: STATUS_ACCESS_VIOLATION at eip=6108D4A4 eax=10040412 ebx=10040412 ecx=0000006D edx=00000000 esi=0241FC98 edi=10040412 ebp=0241FC14 esp=0241FC08 program=C:\cygwin\bin\psql.exe cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023 Stack trace: Frame Function Args 0241FC14 6108D4A4 (10040412, 00000000, 0000006D, 61033C93) 0241FC54 61033CB4 (00000003, 10040410, 0241FC98, 610529AF) 0241FDD4 6798287D (100403D0, 00000001, 100403D0, 6798319F) 0241FE04 67982549 (100403D0, 0040CD7F, 0241FE44, 67981C70) 0241FE44 67981EE5 (00000000, 00000000, 00000000, 00000000) 0241FEB4 0040D1C9 (00000002, 615624B0, 10040278, 00000000) 0241FF10 61003F8E (00000000, 00000000, 0A01FA30, C0504D3C) 0241FF40 61004282 (0040CF38, 0A01FA30, 843696E0, F5CD3C70) 0241FF60 610042C1 (00000000, 00000000, 84369870, 00000005) 0241FF90 004191E3 (0040CF38, FFFFFFFF, 80430D77, 00000000) 0241FFC0 0040103D (0A01FA30, 0022F7E8, 7FFDF000, 00000000) 0241FFF0 77E97D08 (00401000, 00000000, 000000C8, 00000100) End of stack trace ### CREATELANG I also had trouble running createlang. After creating a database using the pgAdmin II interface, I tried createlang plpgsql databasename and I get Signal 11 createlang: external error I was working fine with everything in 7.1.3 in cygwin, all the troubles have started since putting 7.2.2 on.
Tim,
On Mon, Feb 25, 2002 at 06:56:14PM +0000, Tim Finch, FosterFinch Ltd wrote:
> 7.1.3 psql gives this stackdump text file, seemingly the same error then
> that psql 7.2.2 gives???
> I am not a C or 'internals of Unix' programmer but have a pretty good grasp
> of generally whats going on, but obviously am at a dead end myself now. If
> anyone can offer help that would be great. Thanks in advance.
Just install a Cygwin post-1.3.9 snapshot:
http://cygwin.com/snapshots/
BTW, it is 7.2-2 not 7.2.2.
Jason
Thanks Jason, this is same as other advise I have had. Unfortunately I now seem to have killed off the postmaster, which was working before. I posted a message earlier today outlining that fault, if you have any ideas, that would be great. I may remove all of cygwin & try again from scratch. Typically it was all working great in 7.1.3 - all the troubles started when I put on 7.2-2. However I do have problems with doing that : how do I remove the postmaster Win2000 service? Secondly, I have managed to get a copy of the cygwin1.dll in C:|winnt\system32 that cygwin complains about with 'whats that doing there?' but I don't seem to the able to remove it.... giving me access denied, even logged on as administraotr. I renamed it to duffer.dll rebooted but it still won't go. ARRGGH! Any help anyone can give would be most welcome! Thanks Tim. At 08:39 26/02/2002 -0500, Jason Tishler wrote: >Tim, > >On Mon, Feb 25, 2002 at 06:56:14PM +0000, Tim Finch, FosterFinch Ltd wrote: > > 7.1.3 psql gives this stackdump text file, seemingly the same error then > > that psql 7.2.2 gives??? > > I am not a C or 'internals of Unix' programmer but have a pretty good > grasp > > of generally whats going on, but obviously am at a dead end myself now. If > > anyone can offer help that would be great. Thanks in advance. > >Just install a Cygwin post-1.3.9 snapshot: > > http://cygwin.com/snapshots/ > >BTW, it is 7.2-2 not 7.2.2. > >Jason
Tim,
On Tue, Feb 26, 2002 at 03:01:42PM +0000, Tim Finch, FosterFinch Ltd wrote:
> how do I remove the postmaster Win2000 service?
The following should work:
$ cygrunsrv -R postmaster
> Secondly, I have managed to get a copy of the cygwin1.dll
> in C:|winnt\system32 that cygwin complains about with 'whats that doing
> there?' but I don't seem to the able to remove it.... giving me access
> denied, even logged on as administraotr. I renamed it to duffer.dll
> rebooted but it still won't go. ARRGGH!
Stop all Cygwin processes. From a cmd window, do the following:
C:\> del C:winnt\system32\cygwin1.dll
Jason
Great. I'll give these a go. Should have stayed with 7.1.3 - was working perfectly... Is removing all of cygwin as simple as deleting the cygwin directory on C:\? I guess it is (bar my stupidity with the cygwin1.dll in c:\winnt\system32 that is) Thanks Tim. At 12:49 27/02/2002 -0500, Jason Tishler wrote: >Tim, > >On Tue, Feb 26, 2002 at 03:01:42PM +0000, Tim Finch, FosterFinch Ltd wrote: > > how do I remove the postmaster Win2000 service? > >The following should work: > > $ cygrunsrv -R postmaster > > > Secondly, I have managed to get a copy of the cygwin1.dll > > in C:|winnt\system32 that cygwin complains about with 'whats that doing > > there?' but I don't seem to the able to remove it.... giving me access > > denied, even logged on as administraotr. I renamed it to duffer.dll > > rebooted but it still won't go. ARRGGH! > >Stop all Cygwin processes. From a cmd window, do the following: > > C:\> del C:winnt\system32\cygwin1.dll > >Jason
Tim,
On Wed, Feb 27, 2002 at 11:43:24PM +0000, Tim Finch, FosterFinch Ltd wrote:
> Is removing all of cygwin as simple as deleting the cygwin directory on
> C:\?
Pretty much. However, to be 100% complete that you need to remove the
following registry keys too:
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_USERS\*\Software\Cygnus Solutions
Note the "*" above implies multiple keys -- one for each Windows user
that has used Cygwin.
Jason
Jason, You have been a great help, thanks for all the replies, Tim. At 09:08 28/02/2002 -0500, Jason Tishler wrote: >Tim, > >On Wed, Feb 27, 2002 at 11:43:24PM +0000, Tim Finch, FosterFinch Ltd wrote: > > Is removing all of cygwin as simple as deleting the cygwin directory on > > C:\? > >Pretty much. However, to be 100% complete that you need to remove the >following registry keys too: > > HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions > HKEY_USERS\*\Software\Cygnus Solutions > >Note the "*" above implies multiple keys -- one for each Windows user >that has used Cygwin. > >Jason
Having been doing some rapid acclimatisation to getting postgreSQL running on Windows NT codebase, and learning all about cygipc etc. can I ask a perhaps rather dull question... Why is cygipc not in the cygwin package as its an essential part to make postgreSQL (which IS in the cygwin package) run...? Just a thought. Thanks in advance. Tim.
Tim,
On Sat, Mar 02, 2002 at 10:38:59PM +0000, Tim Finch, FosterFinch Ltd wrote:
> Having been doing some rapid acclimatisation to getting postgreSQL running
> on Windows NT codebase, and learning all about cygipc etc. can I ask a
> perhaps rather dull question... Why is cygipc not in the cygwin package as
> its an essential part to make postgreSQL (which IS in the cygwin package)
> run...?
I have some good news and some bad news... :,)
See the following thread:
http://sources.redhat.com/ml/cygwin-apps/2001-03/msg00226.html
As you can see, I had already suggested including cygipc in the standard
Cygwin distribution. The bad news is for various reasons, it was decided
not to include cygipc.
The good news is that Cygwin will have a daemon real soon now. After
this, adding IPC to Cygwin (the right way) becomes significantly easier.
Hopefully, cygipc can be retired in the very near future.
Jason
Tim, On Sat, Mar 02, 2002 at 06:30:10PM +0000, Tim Finch, FosterFinch Ltd wrote: > You have been a great help, thanks for all the replies, You are welcome -- I'm glad to be of assistance. Jason
PGSTAT : COnnection Refused Error (pgsql 7.2-2 on cygwin 1.3.9+)
От
"Tim Finch, FosterFinch Ltd"
Дата:
Jason, & others on the list, I have reinstalled cygwin today in an attempt to clear the error I was having. I have reinstalled cygwin, and put on a post 1.3.9 snapshot of the dll as suggested to fix the psql problem. I put on cygipc as directed. I followed Jason's text file (NT portion) at http://tishler.net/jason/software/postgresql/postgresql-7.2.README.txt to reinstall. It all goes well until the line to 'net start postmaster' whereby the postmaster starts and stops immediately. The only line in the log file says PGSTAT: connect(2): Connection refused timed at the point when I tried to start the postmaster. Hmmm. something simple I guess but I am now at a loss. I did have 7.1.3 working fine before using same version of cygwin. Any help would be greatly received. Thanks Tim.
Tim, On Sun, Mar 03, 2002 at 09:33:55PM +0000, Tim Finch, FosterFinch Ltd wrote: > I have reinstalled cygwin, and put on a post 1.3.9 snapshot of the dll as > suggested to fix the psql problem. Please use Cygwin 1.3.10 since it is available now. > I put on cygipc as directed. > I followed Jason's text file (NT portion) at > http://tishler.net/jason/software/postgresql/postgresql-7.2.README.txt > to reinstall. It all goes well until the line to 'net start postmaster' > whereby the postmaster starts and stops immediately. > > The only line in the log file says > > PGSTAT: connect(2): Connection refused > > timed at the point when I tried to start the postmaster. Sorry, but I have never seen the above error. However, here are some suggestions to debug your problem: 1. Try starting postmaster from the command line. Do you get the same error? 2. Try deleting the cygipc files: $ rm /tmp/cygipc* /tmp/MultiFile* Any difference? 3. Try to strace the problem: $ rm /usr/bin/postmaster $ cp /usr/bin/postgres.exe /usr/bin/postmaster.exe $ strace -o postmaster.log postmaster ... $ rm /usr/bin/postmaster.exe $ ln -s postgres.exe /usr/bin/postmaster Note that he games before and after the strace above is to temporarily convert postmaster from a symlink to a real Win32 executable. This is necessary because strace is a Mingw app and hence does *not* understand Cygwin symlinks. Any thing obvious in postmaster.log? HTH, Jason
At 07:50 04/03/2002 -0500, you wrote:
>Tim,
>
>
>Please use Cygwin 1.3.10 since it is available now.
done
>1. Try starting postmaster from the command line. Do you get the same
>error?
I am logged in as Administrator and i do
postmaster -i -D /usr/share/postgresql/data &
then it starts and within 4 secs it writes to stderr the same error message
as mentioned already earlier in the thread.
>2. Try deleting the cygipc files:
>
> $ rm /tmp/cygipc* /tmp/MultiFile*
>
>Any difference?
I did, and no.
>3. Try to strace the problem:
I did your 'unlink and copy' procedure then
strace --output=strace.output postmaster -i -D /usr/share/postgresql/data
(not even in background, and all output to stdout)
err. it RAN! I managed to get pgAdmin to connect to it, and even got psql
working (which you may recall was a previous thread issue with it
crashing). Great! So how do you stop strace?? I ended up killing it from
another bash screen.
So then rm'd the postmaster.exe and re linked it, and tried again from the
command line, but this time with the additional -d=4 debug level.
I have cut/pasted this log output from debug level 4 at end of this post. I
have not appended strace.output as it was mega size.
>Any thing obvious in postmaster.log?
Well here it (below) is at '-d 4', but without strace.output (when I did
the strace on postmaster it worked so no error messages in log)
Jason, thanks for the help you give, you have been a REAL help so far. I
have a feeling this is SO incredibly simple to solve... especially as it
ran under strace.
Tim.
<snip>
postmaster: PostmasterMain: initial environ dump:
-----------------------------------------
NUMBER_OF_PROCESSORS=1
PROMPT=$P$G
PWD=/var/log
LOGONSERVER=\\OMNIBOOK450
PROCESSOR_LEVEL=6
OS2LIBPATH=C:\WINNT\system32\os2\dll;
COMSPEC=C:\WINNT\system32\cmd.exe
!C:=C:\cygwin\bin
ALLUSERSPROFILE=C:\Documents and Settings\All Users
SYSTEMDRIVE=C:
COMMONPROGRAMFILES=C:\Program Files\Common Files
PROCESSOR_REVISION=0502
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
COMPUTERNAME=OMNIBOOK450
WINDIR=C:\WINNT
USERPROFILE=C:\Documents and Settings\Administrator
PS1=\[\033]0;\w\007
\033[32m\]\u@\h \[\033[33m\w\033[0m\]
$
PROGRAMFILES=C:\Program Files
!::=::\
USER=Administrator
PROCESSOR_IDENTIFIER=x86 Family 6 Model 5 Stepping 2, GenuineIntel
OS=Windows_NT
OLDPWD=/usr/share/postgresql
PROCESSOR_ARCHITECTURE=x86
TEMP=/cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp
SYSTEMROOT=C:\WINNT
TMP=/cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp
HOMEDRIVE=C:
SHLVL=1
MAKE_MODE=unix
APPDATA=C:\Documents and Settings\Administrator\Application Data
HOMEPATH=\
USERDOMAIN=OMNIBOOK450
USERNAME=Administrator
TERM=cygwin
HOME=/home/Administrator
PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:/cygdrive/c/java/bin:/usr/bin:.
_=/usr/bin/postmaster
-----------------------------------------
FindExec: searching PATH ...
ValidateBinary: can't stat "/usr/local/bin/postgres"
FindExec: found "/usr/bin/postgres" using PATH
invoking IpcMemoryCreate(size=1441792)
FindExec: searching PATH ...
ValidateBinary: can't stat "/usr/local/bin/postmaster"
FindExec: found "/usr/bin/postmaster" using PATH
PGSTAT: connect(2): Connection refused
DEBUG: proc_exit(1)
DEBUG: shmem_exit(1)
DEBUG: exit(1)
</snip>
Tim,
On Tue, Mar 05, 2002 at 02:48:02PM +0000, Tim Finch, FosterFinch Ltd wrote:
> At 07:50 04/03/2002 -0500, you wrote:
> >3. Try to strace the problem:
>
> I did your 'unlink and copy' procedure then
>
> strace --output=strace.output postmaster -i -D /usr/share/postgresql/data
>
> (not even in background, and all output to stdout)
>
> err. it RAN! I managed to get pgAdmin to connect to it, and even got psql
> working (which you may recall was a previous thread issue with it
> crashing).
Unfortunately, using strace can "fix" problems -- especially timing
related ones. This is due to the fact that strace-ing slows down the
traced process.
> Great! So how do you stop strace?? I ended up killing it from
> another bash screen.
Just killing it fine.
> >Any thing obvious in postmaster.log?
>
> Well here it (below) is at '-d 4', but without strace.output (when I did
> the strace on postmaster it worked so no error messages in log)
>
> [snip]
>
> PGSTAT: connect(2): Connection refused
> DEBUG: proc_exit(1)
> DEBUG: shmem_exit(1)
> DEBUG: exit(1)
I grep-ed the code as follows:
$ find . -name '*.[ch]' | xargs fgrep 'PGSTAT: connect'
./src/backend/postmaster/pgstat.c: perror("PGSTAT: connect(2)");
Hence, postmaster is crapping out at the "if" below:
/* ----------
* pgstat_init() -
*
* Called from postmaster at startup. Create the resources required
* by the statistics collector process.
* ----------
*/
int
pgstat_init(void)
{
..
/*
* Connect the socket to its own address. This saves a few cycles
* by not having to respecify the target address on every send. This
* also provides a kernel-level check that only packets from this same
* address will be received.
*/
if (connect(pgStatSock, (struct sockaddr *) & pgStatAddr, alen) < 0)
{
perror("PGSTAT: connect(2)");
close(pgStatSock);
pgStatSock = -1;
return -1;
}
..
}
Are you configuring postmaster to collect stats?
Sorry, but I cannot reproduce your problem so I cannot debug it further.
Jason
Jason, as ever thanks for the reply. Our postings have crossed in the post
- as I have solved the problem, see other post re: Zone Alarm, (Grrrr)
Tim.
At 10:28 05/03/2002 -0500, Jason Tishler wrote:
>Tim,
>
>On Tue, Mar 05, 2002 at 02:48:02PM +0000, Tim Finch, FosterFinch Ltd wrote:
> > At 07:50 04/03/2002 -0500, you wrote:
> > >3. Try to strace the problem:
> >
> > I did your 'unlink and copy' procedure then
> >
> > strace --output=strace.output postmaster -i -D /usr/share/postgresql/data
> >
> > (not even in background, and all output to stdout)
> >
> > err. it RAN! I managed to get pgAdmin to connect to it, and even got psql
> > working (which you may recall was a previous thread issue with it
> > crashing).
>
>Unfortunately, using strace can "fix" problems -- especially timing
>related ones. This is due to the fact that strace-ing slows down the
>traced process.
>
> > Great! So how do you stop strace?? I ended up killing it from
> > another bash screen.
>
>Just killing it fine.
>
> > >Any thing obvious in postmaster.log?
> >
> > Well here it (below) is at '-d 4', but without strace.output (when I did
> > the strace on postmaster it worked so no error messages in log)
> >
> > [snip]
> >
> > PGSTAT: connect(2): Connection refused
> > DEBUG: proc_exit(1)
> > DEBUG: shmem_exit(1)
> > DEBUG: exit(1)
>
>I grep-ed the code as follows:
>
> $ find . -name '*.[ch]' | xargs fgrep 'PGSTAT: connect'
> ./src/backend/postmaster/pgstat.c: perror("PGSTAT:
> connect(2)");
>
>Hence, postmaster is crapping out at the "if" below:
>
>/* ----------
> * pgstat_init() -
> *
> * Called from postmaster at startup. Create the resources required
> * by the statistics collector process.
> * ----------
> */
>int
>pgstat_init(void)
>{
>..
> /*
> * Connect the socket to its own address. This saves a few cycles
> * by not having to respecify the target address on every send. This
> * also provides a kernel-level check that only packets from this same
> * address will be received.
> */
> if (connect(pgStatSock, (struct sockaddr *) & pgStatAddr, alen) < 0)
> {
> perror("PGSTAT: connect(2)");
> close(pgStatSock);
> pgStatSock = -1;
> return -1;
> }
>..
>}
>
>Are you configuring postmaster to collect stats?
>
>Sorry, but I cannot reproduce your problem so I cannot debug it further.
>
>Jason
Tim Finch,
FosterFinch Ltd
http://www.fosterfinch.co.uk
Jason, & list members, Well I have solved the problem of the PGSTAT : Connection refused error. ZoneAlarm After going round the houses attempting to sus the problem, I suddenly had a momentary lapse of reason and thought that Zonealarm could be affecting things. I of course registered postmaster, postgres.exe and psql.exe as programs to allow traffic, when I first installed 7.1.3 postgresql in cygwin 1.3.9. for some reason, unexplainable to me, the settings inside Zonealarm must have got confused because they were now working against me. I went to the Programs list and removed the entries from zone alarm, and then tried starting the postmaster (the point at which I had been getting the PGSTAT Connection refused message many times in the last few days) and ... IT WORKED!!! Of course Zonealarm asked me'do you want to allow postmaster to ....' and I duly responded. They are now all back in the list in Zone Alarm and no longer complaining.... So, for anyone reading this, or searching the archives and reading this, CHECK YOUR FIREWALL! May it be pertinent to add a line in the docs that go with the builds of Pgsql in cygwin to say something similar? Many many thanks to Jason on this list for all his help in solving this trouble. Despite the fact it was nothing to do with pgsql or cygwin, its nice to know someone could hear my cries. The process of attempting to fix it has of course been a real learning experience and now I understand much more about cygwin, pgsql installs etc. etc. I suppose, I could have always turned my red hat box back on but that would have been cheating now wouldn't it!! Tim.