Re: [HACKERS] fork/exec for backend

Поиск
Список
Период
Сортировка
От Tom
Тема Re: [HACKERS] fork/exec for backend
Дата
Msg-id Pine.BSF.3.95q.980124145035.19914D-100000@misery.sdf.com
обсуждение исходный текст
Ответ на Re: [HACKERS] fork/exec for backend  (Goran Thyni <goran@bildbasen.se>)
Ответы Re: [HACKERS] fork/exec for backend  (Goran Thyni <goran@bildbasen.se>)
Список pgsql-hackers
On 24 Jan 1998, Goran Thyni wrote:

>    On 24 Jan 1998, Goran Thyni wrote:
>
>    > Fork on modern unices (linux and (a think) *BSD) cost
>    > almost nothing (in time and memory) thanks to COW (copy-on-write).
>    > Exec in expensive as it breaks COW.
>
>      Not so.  Modern Unixs will share executable address space between
>    processes.  So if you fork and exec 10 identical programs, they will share
>    most address space.
>
> 1. Code is probably not shared between postmaster and postgres
>    processes.

  A backend is execed for every connection.  All the backends will share
code space.

> 2. Some inits may be done once (by postmaster) and not repeated
>    by every child.

  Not relevant.  I'm only concerned with the children.

> 3. (and most important)
>    With no exec COW is in action, meaning:
>    data pages in shared until changed.
>
> COW is the key to how Linux can fork faster than most unices
> starts a new thread. :-)

  COW is old news.  Perhaps you can find some old SCO systems that don't
do COW :)

>      Again, this only applies to "modern" systems, but FreeBSD definitely has
>    this behaviour.
>
> I don't know if *BSD has COW, but if should think so.

  I'm not speaking just about COW, but about being able share code between
separately execed processes.

>   best regards,
> --
> ---------------------------------------------
> G�ran Thyni, sysadm, JMS Bildbasen, Kiruna

Tom


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

Предыдущее
От: Rick Poleshuck
Дата:
Сообщение: Revoke update on Column
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] fork/exec for backend