From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov> |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Trouble in paradise: cancel via postmaster ain't so cool |
Date: | 1998-07-08 13:56:17 |
Message-ID: | 24587.899906177@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Henry B. Hotz" <hotz(at)jpl(dot)nasa(dot)gov> writes:
> Idea A: precompute everything you need to do a cancel as part of sending
> the request in the first place so #1 above takes minimum effort (i.e. no
> malloc(), no gethostbyname(), no nothing).
Yeah, that's what I planned to try. It'll mean making the PGconn
structure a little bigger to hold the info, but that seems OK.
> Idea B: spawn (vfork()/exec()) a cancel process so all the funny stuff
> happens in a different address space.
Hadn't thought of that one... it'd have to be a real fork not a vfork,
consequently could be pretty expensive for a large application.
Still it might be a better answer than living with a nonreentrant
PQrequestCancel().
After sleeping on it, I feel like it should be possible to solve the
problem along the lines Henry mentions: have connectDB save everything
that it needs to get from C library routines, so that only kernel calls
are needed to open a new postmaster connection in PQrequestCancel.
Will work on that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Hartwig | 1998-07-08 16:01:01 | Re: [HACKERS] Access & Postgres |
Previous Message | Sferacarta Software | 1998-07-08 13:35:06 | Re[2]: [GENERAL] COALESCE() or NVL() |