Re: [HACKERS] why do shmem attach?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] why do shmem attach? |
Дата | |
Msg-id | 13849.937838191@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] why do shmem attach? (Vadim Mikheev <vadim@krs.ru>) |
Список | pgsql-hackers |
Vadim Mikheev <vadim@krs.ru> writes: >> I don't think it's worth messing with either. It'd be nice for code >> beautification purposes to (a) combine the three shared-mem segments >> we currently have into one, and (b) rely on the postmaster's having > I would try to use more than one segment for buffer pool if > max seg size is not enough for all buffers. Ah, that would be a nice end-run around kernels with small SHMMAX, wouldn't it? >> I'm also a little worried that we'd be >> sacrificing portability --- some day we might be glad that we can >> move those segments around... > We can't. MAKE_OFFSET/MAKE_PTR was used because of after > fork/exec/shmat backend' ShmemBase was different from > postmaster' one. But we can't move *BufferDescriptors > if some running backend already uses BufferDescriptors. Right, we can't relocate a segment within the address space of an already-running backend. What I meant was that being able to put it at different addresses in different backends might be needed again someday, even though right now we don't need it. > But I agreed - this is not high-priority task -:) Yup. Plenty of high-priority ones, too... regards, tom lane
В списке pgsql-hackers по дате отправления: