Skip site navigation (1) Skip section navigation (2)

Re: Win32 open items

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Magnus Hagander <mha(at)sollentuna(dot)net>
Cc: pgsql-hackers-win32(at)postgresql(dot)org,"Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
Subject: Re: Win32 open items
Date: 2004-10-28 11:19:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32
Magnus Hagander wrote:
> > After 4 weeks of work, involving alot of bug fixes, and 
> > documentation improvements, to the source tree, we have just 
> > released our 4th Beta of 8.0.0.  Most of the items on Bruce's 
> > Open Items list have been completed, but we still have a half 
> > dozen or so Windows related items still open.
> A couple of notes on the three windows items that are open (can't speak
> for the non-windows ones that are actually more :P):
> * Query cancel in psql
> I see two ways of doing this. One is to take the easy way out and just
> add a console ctrl handler and let it do a standard query cancel. The
> problem with this is that PQrequestCancel() is not thread-safe. Which
> means we have a possible crash there, but only if we're either
> PQfinish():ing the connection in the main thread, or if we're accessing
> the error members (either reading or setting). If this is acceptable,
> the fix for psql is really simple.
> If this is not acceptable, we have to do something along the line of
> what's done in the backend to handle signals - we need to implement a
> "signals aware" PQexec(). This function would have to call the async
> query functions, and then wait for both these and an internal event to
> look for cancel events. This is clearly the safest bet, but it's
> definitly more work.
> Anybody have any other ideas that happen to be as simple as the first
> optino but safer? Please ;-)

I have an idea on this one.   I think we need to put locking around
access to psql/common.c::cancelConn so that we are sure the signal
handler is not accessing it while it is being modified.  We already have
thread locking primitives for Win32 in libpq and we are sure the
standard C functions are thread-safe on WIn32 because there are no
special thread compile flags for Win32.  We also might need to make
cancelConn a copy of the PGconn structure rather than just a pointer.

I can't think of how to simulate the longjump() currently used when
cancelConn is NULL though.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-hackers-win32 by date

Next:From: Magnus HaganderDate: 2004-10-28 11:55:53
Subject: Re: Win32 open items
Previous:From: Bruce MomjianDate: 2004-10-27 19:43:55
Subject: Re: pg_ctl strangeness under msys

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group