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

Re: [pgsql-hackers-win32] 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,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [pgsql-hackers-win32] Win32 open items
Date: 2004-10-29 19:08:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-hackers-win32
Magnus Hagander wrote:
> It won't work unless you make it a copy, I think. Because you'd have to
> lock the entire structure whenever you called PQexec() (since you don't
> know when PQexec does things), and that's just the time when you'd need
> to use it from the other thread...
> As for making a copy, yes, that's the other optino I had, but completely
> had lost when I wrote that mail. However, it cannot be done in just
> pqsl, because psql doesn't see the contents of PGconn. We'd need at
> least one new libpq function to create a duplicate PGconn. In order to
> be safe, this should probably be a for-cancel-only-copy, so we shouldn't
> copy the whole PGconn. But we could copy whatever fields are required to
> cancel the query, which in turn would require a new cancelilng function
> that accepted this limited structure.
> Probably doable, but it requires API additions, I think.

I thought about this.  There are a lot of pointers in PGconn, and most
we don't use so I don't like the idea of adding a new API to copy the
complex PGconn structure just for Win32 psql cancel.  Looking at the
PQrequestCancel() code, it only writes to errorMessage and reads from
everything else, and I don't see any of those changing (except
errorMessage) once the connection is established, so we could do a
non-deep copy of the structure and reuse all the existing structure
pointers.  We would just need to create a new errorMessage structure
because PQrequestCancel() wants to write to that.

We do need to use locking while we create/destroy this structure.

> > I can't think of how to simulate the longjump() currently 
> > used when cancelConn is NULL though.
> Um. No need for that on win32, I think. When cancelConn is NULL (I am
> now assuming we have solved the fact that cancelConn has to be a copy),
> we can just do a "return" from the signal handler. The therad will then
> happily end, and we're all fine. Or is it supposed to do something other
> than just ignoring the cancel request if cancelconn is NULL?

Agreed, we can just ignore it.

  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 by date

Next:From: Michael GuerinDate: 2004-10-29 19:15:41
Subject: Postgresql crash- any ideas?
Previous:From: Tom LaneDate: 2004-10-29 14:50:48
Subject: Re: tablespaces for temporary files

pgsql-hackers-win32 by date

Next:From: Tom LaneDate: 2004-10-29 19:46:55
Subject: Re: [pgsql-hackers-win32] Win32 open items
Previous:From: Magnus HaganderDate: 2004-10-28 11:55:53
Subject: Re: Win32 open items

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