Re: [HACKERS] Trouble in paradise: cancel via postmaster ain't so cool

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Trouble in paradise: cancel via postmaster ain't so cool
Дата
Msg-id 24587.899906177@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Trouble in paradise: cancel via postmaster ain't so cool  ("Henry B. Hotz" <hotz@jpl.nasa.gov>)
Список pgsql-hackers
"Henry B. Hotz" <hotz@jpl.nasa.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Herouth Maoz
Дата:
Сообщение: Re: [GENERAL] translate "bug"?
Следующее
От: jwieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [PG95-DEV] Rule system