Thread: initdb failure - postgres hangs with 100% CPU
I am attempting to create a postgresql database under cygwin: $ uname -a CYGWIN_NT-4.0 WCA22291271 1.3.2(0.39/3/2) 2001-05-20 23:28 i686 unknown on a WinNT Workstation. WinNT 4.0 SP5 $ echo $PGDATA /usr/share/postgresql/data nbk3r4y@WCA22291271 ~ $ initdb -d > initdb.log 2>&1 & [2] 213 nbk3r4y@WCA22291271 ~ $ tail -f initdb.log PG_IDENT_SAMPLE=/usr/share/postgresql/pg_ident.conf.sample This database system will be initialized with username "nbk3r4y". This user will own all the data files and must also own the server process. Creating directory /usr/share/postgresql/data Creating directory /usr/share/postgresql/data/base Creating directory /usr/share/postgresql/data/global Creating directory /usr/share/postgresql/data/pg_xlog Creating template1 database in /usr/share/postgresql/data/base/1 Running: /usr/bin/postgres -boot -x1 -C -F -D/usr/share/postgresql/data -d templ ate1 At this point the NT system hangs. The Win Task manager shows the proesser pegged at 100% utilization by initdb. cgywin "top" tells the same story. % Pid Tid Pri Key Start Address ImageName ___________________________________________________________________ 99% 340 609 2502656 2195456 0:00:45.745 postgres.exe 0% 30 4529 1118208 1605632 0:00:07.671 CSRSS.EXE initdb never comes back. This user ID has NT local administrator rights. Please let me know why postgres is dieing at this point. Thanks, Michael Williams __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
You need to have ipc-daemon running 1st I found these 2 url's to be very informative. http://people.freebsd.org/~kevlo/postgres/portNT.html http://ontosys.com/reports/postgresql.html Jon -----Original Message----- From: pgsql-cygwin-owner@postgresql.org [mailto:pgsql-cygwin-owner@postgresql.org] On Behalf Of Michael Williams Sent: Thursday, June 28, 2001 3:18 PM To: pgsql-cygwin@postgresql.org Cc: cygwin@sources.redhat.com Subject: [CYGWIN] initdb failure - postgres hangs with 100% CPU I am attempting to create a postgresql database under cygwin: $ uname -a CYGWIN_NT-4.0 WCA22291271 1.3.2(0.39/3/2) 2001-05-20 23:28 i686 unknown on a WinNT Workstation. WinNT 4.0 SP5 $ echo $PGDATA /usr/share/postgresql/data nbk3r4y@WCA22291271 ~ $ initdb -d > initdb.log 2>&1 & [2] 213 nbk3r4y@WCA22291271 ~ $ tail -f initdb.log PG_IDENT_SAMPLE=/usr/share/postgresql/pg_ident.conf.sample This database system will be initialized with username "nbk3r4y". This user will own all the data files and must also own the server process. Creating directory /usr/share/postgresql/data Creating directory /usr/share/postgresql/data/base Creating directory /usr/share/postgresql/data/global Creating directory /usr/share/postgresql/data/pg_xlog Creating template1 database in /usr/share/postgresql/data/base/1 Running: /usr/bin/postgres -boot -x1 -C -F -D/usr/share/postgresql/data -d templ ate1 At this point the NT system hangs. The Win Task manager shows the proesser pegged at 100% utilization by initdb. cgywin "top" tells the same story. % Pid Tid Pri Key Start Address ImageName ___________________________________________________________________ 99% 340 609 2502656 2195456 0:00:45.745 postgres.exe 0% 30 4529 1118208 1605632 0:00:07.671 CSRSS.EXE initdb never comes back. This user ID has NT local administrator rights. Please let me know why postgres is dieing at this point. Thanks, Michael Williams __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Michael,
On Thu, Jun 28, 2001 at 12:18:20PM -0700, Michael Williams wrote:
> I am attempting to create a postgresql database under
> cygwin:
>
> [snip]
>
> At this point the NT system hangs. The Win Task
> manager shows the proesser pegged at 100% utilization
> by initdb. cgywin "top" tells the same story.
Did you read item 4 in the PostgreSQL MS Windows FAQ?
http://postgresql.bteg.net/docs/faq-mswin
Did you read installation steps 1 - 3 in the Cygwin PostgreSQL README?
/usr/doc/Cygwin/postgresql-7.1.2.README
Jason
--
Jason Tishler
Director, Software Engineering Phone: 732.264.8770 x235
Dot Hill Systems Corp. Fax: 732.264.8798
82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com
[I apologize to the Cygwin and PostgreSQL communities for the following
rant. I slept on this one before responding. I guess that sleeping on
it didn't really help.]
Clark,
Just curious... But, don't you have anything better to do than
send provocative, unsolicited email? If you have something to say
(constructive or otherwise), then use the appropriate mailing instead
of sending private mail.
On Mon, Jul 09, 2001 at 05:07:58PM -0400, Clark C . Evans wrote:
> | Did you read installation steps 1 - 3 in the Cygwin PostgreSQL README?
> | /usr/doc/Cygwin/postgresql-7.1.2.README
>
> If it doesn't run out of the box, why have it
> in cygwin base distribution? just curious...
Why? Because I'm extremely selfish -- plain and simple. The sole
reason that I contributed Python and PostgreSQL to Cygwin was just to
stem the tide of unsolicited emails requesting help to apply my patches,
set up a Cygwin development environment, build the packages, etc.
It never crossed my mind that:
o I should give back to the open source community instead of just
taking.
o Cygwin users would actually find it useful and convenient to have
pre-built Python and PostgreSQL packages available.
o I should spend more time with my children or sleep instead of
spending a significant fraction of my free time devising patches,
submitting patches, pleading Cygwin's case, resubmitting revised
patches, etc.
If the Cygwin PostgreSQL distribution does not meet your needs, then
just instruct Cygwin's setup.exe to skip installing it.
> if you include postgresql, shouldn't cygipc be
> included as well?
I have already suggested the above. Due to valid licensing and technical
issues, it was decided not to add cygipc to the Cygwin distribution.
Search the archives, if you are just curious about the details.
I responded to another one of your just curious emails:
http://mail.python.org/pipermail/python-list/2001-April/039337.html
with diligence that ended up consuming a lot of Tim Peters, DJ Delorie,
and my time. I will not be extending you that courtesy again.
Jason
--
Jason Tishler
Director, Software Engineering Phone: 732.264.8770 x235
Dot Hill Systems Corp. Fax: 732.264.8798
82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Steve,
On Tue, Jul 10, 2001 at 10:57:11AM -0700, Steve Jorgensen wrote:
> In case you were wondering, I am someone who has been -very- happy to have
> your Cygwin port of PostgreSQL to work with, and I had no problem following
> your instructions to make it work. Just so you know your work is
> appreciated.
Thanks for acknowledging my efforts.
> Trojan horse follows:
> I don't suppose you know if anyone has instructions for building libpq.dll
> using Cygwin/gcc?
What precisely do you mean by "libpq.dll"? Do you mean the straight Win32
version of libpq, the PostgreSQL front-end C library? If so, then you can
find a pre-built (with MSVS 6.0) but *untested* tarball at the following:
http://members.home.net/jtishler/software/postgresql/postgresql-7.1.2-1-win32.tar.gz
By "using Cygwin/gcc" do you mean Cygwin's gcc -mno-cygwin or Mingw
mode? If so, then it should be possible but I don't know of anyone who
has done it yet.
Jason
--
Jason Tishler
Director, Software Engineering Phone: 732.264.8770 x235
Dot Hill Systems Corp. Fax: 732.264.8798
82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Jason, My sincere apologies for ignorance and for being provocative, it came without any justification. I do cherish your python and postgresql contribution to cygwin and look forward to trying plpython. This whole thing came after significant hair pulling trying to get PostgreSQL compile and run with Active State's Python (I need threads). For some reason, me being very tired probably contributing, when I read your posting, it made me remember the FAQ_MSWIN so I jumped immediately there (without going to /usr/doc/Cygwin) and figured out the problem with cygipc. After getting it all to work, I sent off the message to you _privately_ to ask why it didn't install out of the box... It would figure that this is a licensing issue, oh bother. Bugger me for not even reading /usr/doc/Cygwin/postresql-7.1.2.README Apologies, Clark P.S. I do think it would be helpful if the package specific readme files were in /usr/doc rather than /usr/doc/Cygwin. Up till now I didn't even know that /usr/doc/Cygwin existed.
Clark, On Tue, Jul 10, 2001 at 02:26:28PM -0400, Clark C . Evans wrote: > My sincere apologies for ignorance and for being > provocative, it came without any justification. Apology accepted. > I do cherish your python and postgresql contribution > to cygwin and look forward to trying plpython. I'm pleased to hear that you appreciate my Cygwin Python and PostgreSQL packages. BTW, if you are willing to use the current PostgreSQL CVS, then you can try out plpython now -- all of the required Cygwin patches have already been submitted and accepted. You don't have to wait for PostgreSQL 7.2. > This whole thing came after significant hair pulling > trying to get PostgreSQL compile and run with Active > State's Python (I need threads). Thanks to Rob Collins and Greg Smith, significant progress has been made on Cygwin's pthreads support. Hopefully, I will be releasing a Cygwin Python that supports threading soon. Jason -- Jason Tishler Director, Software Engineering Phone: 732.264.8770 x235 Dot Hill Systems Corp. Fax: 732.264.8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Jason Tishler wrote:
> By "using Cygwin/gcc" do you mean Cygwin's gcc -mno-cygwin or Mingw
> mode? If so, then it should be possible but I don't know of anyone who
> has done it yet.
I have compiled and successfully tested libpq with mingw, including ecpg support. See my
posting on psql-cygwin and mingw-users on july 2nd.
Binaries are at ftp://midgard.berlios.de/pub/midgard/
Of course unix sockets are not supported under MinGW, you have to use TCP/IP.
Yours
Christof
Re: Libpq.dll on MinGW, was Re: initdb failure - postgres hangs with 100% CPU
From
Jason Tishler
Date:
Christof, On Wed, Jul 11, 2001 at 01:30:16PM +0200, Christof Petig wrote: > Jason Tishler wrote: > > > By "using Cygwin/gcc" do you mean Cygwin's gcc -mno-cygwin or Mingw > > mode? If so, then it should be possible but I don't know of anyone who > > has done it yet. > > I have compiled and successfully tested libpq with mingw, including ecpg > support. See my posting on psql-cygwin and mingw-users on july 2nd. I actually read that email, but was on vacation at the time, so it went right out of my mind -- those pesky holidays and vacations getting in the way yet again! :,) I have reviewed your patch. IMO, only some of it would be accepted into the mainline source by the PostgreSQL development team. However, I feel that your work is important and a very good start. Would you be willing to take this to the next level? First, you would need to make a new Mingw Makefile (src/makefiles/Makefile.mingw) and port header file template (src/include/port/mingw.h). Then, diddle with the autoconf stuff to select these new templates. Finally, you would need to convince make to just build the Mingw build-able stuff. BTW, when reviewing your patch, I noticed a hunk against config.h. Did you configure under Cygwin first and then make your changes? If not, how was config.h generated? I would be willing to review your patches before you submit then to pgsql-patches. Jason -- Jason Tishler Director, Software Engineering Phone: 732.264.8770 x235 Dot Hill Systems Corp. Fax: 732.264.8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Steve,
In the future, please keep your replies to the list(s).
On Tue, Jul 10, 2001 at 02:04:02PM -0700, Steve Jorgensen wrote:
> [Steve Jorgensen] Yes, that's what I meant. After much searching, I had
> found your untested tarball previously. I tested it somewhat, by the way,
> and it functions with the native Windows version of pgAccess, though I
> haven't worked it very hard.
I thought that they would work. Thanks for testing them.
> I would like to learn to fish, though rather
> than just have the fish so I can make my own libpq.dll for any new version
> of PostgreSQL when the source is released.
I this case fishing is easy but expensive. If you install MSVS 6.0,
then all you need to do is:
$ nmake -f win32.mak
> I tried just configuring with a
> target of i586-pc-win32, then running make in the libpq directory - I had
> no errors, but only got pq.dll, not libpq.dll. I don't even know what
> pq.dll is.
You just did the configure for building under Cygwin. pq.dll is the
Cygwin version of libpq.dll.
> By "using Cygwin/gcc" do you mean Cygwin's gcc -mno-cygwin or Mingw
> mode? If so, then it should be possible but I don't know of anyone who
> has done it yet.
>
> [Steve Jorgensen] Yes, that's what I meant. Thanks for your reply.
I presume that you saw the recent activity regarding the above. Why don't
you give Christof's patches a shot?
Jason
--
Jason Tishler
Director, Software Engineering Phone: 732.264.8770 x235
Dot Hill Systems Corp. Fax: 732.264.8798
82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com
From: "Jason Tishler" <Jason.Tishler@dothill.com> >> I would like to learn to fish, though rather >> than just have the fish so I can make my own libpq.dll for any new version > If you install MSVS 6.0, then all you need to do is: > $ nmake -f win32.mak i've tried that some time ago. it worked ok until i tried to fetch large text fields. some investigation shown: it appears that recv() and send() do not set errno. so pqReadData didn't seen EWOULDBLOCK and complained about failed read(). replacing errno with WSAGetLastError() fixed that. /Dmitry
Re: Libpq.dll on MinGW, was Re: initdb failure - postgres hangs with 100% CPU
From
Christof Petig
Date:
Hi Jason, > I actually read that email, but was on vacation at the time, so it went > right out of my mind -- those pesky holidays and vacations getting in > the way yet again! :,) I'm heading for four weeks holiday in 8 days, so I'm quite busy with paid work + preparing things ... > Would you be willing to take this to the next level? First, you would > need to make a new Mingw Makefile (src/makefiles/Makefile.mingw) and port > header file template (src/include/port/mingw.h). Then, diddle with the > autoconf stuff to select these new templates. Finally, you would need > to convince make to just build the Mingw build-able stuff. Brrr. I hate platform specific Makefiles. Once somebody changes the master Makefile you have to port every change yourself. (As happened e.g. with glib!) Usually I prefer either short build scrips (calling make, patch, install etc.) or plain autoconf/automake. But if it's usual within Pgsql, it will be the way to go. Perhaps later (September). I meant my mail as a 'It's possible, I made it this way' message. > BTW, when reviewing your patch, I noticed a hunk against config.h. Did > you configure under Cygwin first and then make your changes? If not, > how was config.h generated? Oh, I knew. I simply didn't go that far. Since I'm maintainer of some other OSS projects I don't have too much free time, perhaps someone else wants to step in the gap? Christof PS: The port was done on a MinGW cross compiler on an iBook (debian PPC). PPS: I took cygwin out of the CC list since it get's more internal to pgsql.
Dmitry, On Thu, Jul 12, 2001 at 03:59:58AM +0400, Dmitry Yurtaev wrote: > From: "Jason Tishler" <Jason.Tishler@dothill.com> > > >> I would like to learn to fish, though rather > >> than just have the fish so I can make my own libpq.dll for any new > version > > If you install MSVS 6.0, then all you need to do is: > > $ nmake -f win32.mak > > i've tried that some time ago. it worked ok until i tried to fetch large > text fields. some investigation shown: it appears that recv() and send() do > not set errno. so pqReadData didn't seen EWOULDBLOCK and complained about > failed read(). replacing errno with WSAGetLastError() fixed that. Would you be willing to submit a patch to correct this problem? I expect that it would be gladly accepted. Jason -- Jason Tishler Director, Software Engineering Phone: 732.264.8770 x235 Dot Hill Systems Corp. Fax: 732.264.8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com