| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Vadim Mikheev <vadim(at)krs(dot)ru> |
| Cc: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Developers List <hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] why do shmem attach? |
| Date: | 1999-09-20 14:36:31 |
| Message-ID: | 13849.937838191@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Vadim Mikheev <vadim(at)krs(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 1999-09-20 14:49:10 | Re: [HACKERS] why do shmem attach? |
| Previous Message | Tom Lane | 1999-09-20 14:28:08 | Re: [HACKERS] couldn't rollback cache ? |