回复：Attach to shared memory after fork()

> Windows has CreateProcess, which isn't available elsewhere.
Yes, we still need fork() on *nix. So the solution is to reduce the
overhead of fork(). Attach to shared memory after fork() might be a
"Better shared memory management".

> This is one of the reasons for using a connection pooler like pgbouncer,
> which can vastly reduce the number of new process creations Postgres has
to do.
Yes, it’s another way I forgot to mention. But I think there should be a
cleaner way without other component.

> This proposal seems moderately insane. In the first place, it
> introduces failure modes we could do without, and in the second place,
> how is it not strictly *more* expensive than what happens now? You
> still have to end up with all those TLB entries mapped in the child.
Yes, the idea is radical. But it’s practical.
1. I don’t quite catch that. Can you explain it?
2. Yes, the overall cost is still the same, but the cost can spread
into multi processes thus CPUs, not 100% on Postmaster.

> (If your kernel is unable to pass down shared-memory TLBs effectively,
> ISTM that's a kernel shortcoming not a Postgres architectural problem.)
Indeed, it’s a kernel/CPUarch shortcoming. But it is also a Postgres
architectural problem. MySQL and Oracle have no such problem.
IMHO Postgres should manage itself well(eg. IO/buffer pool/connection/...)
and not rely so much on OS kernel...

The fork() used to be a genius hack, but now it’s a burden and it will get
worse and worse. All I want to do is remove fork() or reduce the overhead.
Maybe *nux will have CreateProcess someday(and I think it will), and we
should wait for it?