Re: dynamic loading of .so
От
Cristian Prieto
Тема
Re: dynamic loading of .so
Дата
Msg-id
00ca01c5d322$3f897910$6500a8c0@gt.ClickDiario.local
Ответ на
Re: dynamic loading of .so (Tom Lane)
Список
Дерево обсуждения
dynamic loading of .so TJ O'Donnell <tjo@acm.org>
Re: dynamic loading of .so Douglas McNaught <doug@mcnaught.org>
Re: dynamic loading of .so <cristian@clickdiario.com>
Re: dynamic loading of .so Douglas McNaught <doug@mcnaught.org>
Re: dynamic loading of .so Tom Lane <tgl@sss.pgh.pa.us>
Re: dynamic loading of .so "Cristian Prieto" <cristian@clickdiario.com>
You are talking about a shmem block using by the backend, right? Or about my "own" shmem block?. I'm very interested in the implementation of a "constants" like functionality to pgsql, but I don't know where to start with... Any help or ideas? -----Original Message----- From: Tom Lane [mailto:tgl@sss.pgh.pa.us] Sent: Domingo, 16 de Octubre de 2005 10:42 p.m. To: Douglas McNaught Cc: cristian@clickdiario.com; tjo@acm.org; pgsql-general@postgresql.org Subject: Re: [GENERAL] dynamic loading of .so Douglas McNaught writes: > writes: >> are there any way to make them global for all the instances? > Put them in shared memory. This probably isn't trival, as all the > shared memory is allocated up front and used for existing purposes (at > least, as I understand it). There's a "slop factor" of 100KB or so in the shared memory size calculation, which means that an add-on library that requests space soon enough could probably get away with allocating up to a few KB without causing any problems. (The slop is not totally useless, since for instance the lock manager might eat it up if more locks get requested than expected.) In the long run it might be interesting to add hooks that allow preloaded libraries to contribute to the shmem sizing calculation and then to snarf up the space they've requested before it can get eaten by the lockmgr. regards, tom lane
В списке pgsql-general по дате отправления