Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com X-Authentication-Warning: shell-3.enteract.com: fcy set sender to fred AT ontosys DOT com using -f Date: Tue, 8 May 2001 14:24:27 -0500 From: Fred Yankowski To: pgsql-cygwin AT postgresql DOT org Cc: cygwin AT cygwin DOT com Subject: SIGTERM does not stop backend postgres processes immediately Message-ID: <20010508142427.A25541@enteract.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i It seems that postgres backend processes built with Cygwin do not react to the SIGTERM signal immediately. Instead, they remain blocked on a recv() call deep under ReadCommand() and don't notice the signal until data comes in over the socket connection and unblocks recv(). This prevents a 'fast' stop of the whole PostgreSQL instance from working correctly. I'm seeing this problem in Cygwin 1.3.1 with cygipc-1.09-2, using PostgreSQL built from source based on a very recent CVS snapshot. This problem sounds similar to one reported in the pgsql-ports list earlier this year [1]. That thread concludes that it's a Cygwin problem, but with no solution yet. Has there been any progress since then? [1] http://postgresql.readysetnet.com/mhonarc/pgsql-ports/2001-01/msg00023.html -- Fred Yankowski fred AT OntoSys DOT com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple