Re: [PATCHES] A patch for xlog.c
От | Bruce Momjian |
---|---|
Тема | Re: [PATCHES] A patch for xlog.c |
Дата | |
Msg-id | 200102260448.XAA23149@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] A patch for xlog.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > It allows no backing store on disk. It is the BSD solution to SysV > > share memory. Here are all the BSDi flags: > > > MAP_ANON Map anonymous memory not associated with any specific file. > > The file descriptor used for creating MAP_ANON must be -1. > > The offset parameter is ignored. > > Hmm. Now that I read down to the "nonstandard extensions" part of the > HPUX man page for mmap(), I find > > If MAP_ANONYMOUS is set in flags: > > o A new memory region is created and initialized to all zeros. > This memory region can be shared only with descendants of > the current process. > > While I've said before that I don't think it's really necessary for > processes that aren't children of the postmaster to access the shared > memory, I'm not sure that I want to go over to a mechanism that makes it > *impossible* for that to be done. Especially not if the only motivation > is to avoid having to configure the kernel's shared memory settings. Agreed. It would make it impossible and a possible limitation. > Besides, what makes you think there's not a limit on the size of shmem > allocatable via mmap()? I figured mmap() was different than SysV becuase mmap() is file based. I have had this item on the TODO list for a while: * Use mmap() rather than SYSV shared memory(?) Should I remove it? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: