Re: [HACKERS] Hardwired MAXBACKENDS limit could be history
> It would require only very minor changes in the main backend code to > eliminate entirely the hard-wired upper bound MAXBACKENDS. This would > be nice since there'd never be any need to recompile in order to > increase the soft limit MaxBackends (-N). However I see that the > SysV-semaphore emulation code used by the QNX and Darwin ports still > makes use of MAXBACKENDS to size some arrays. I don't especially want > to touch that code, since I am in no position to test it. Perhaps > someone who uses QNX and/or Darwin would like to tweak the sema code > to not depend on a compile-time-constant MAXBACKENDS? > > I'm not thinking about getting this done in time for 7.1, but I think > it'd be a nice cleanup for 7.2. > > Bruce, a TODO item please: > * Remove compile-time upper limit on number of backends (MAXBACKENDS) Added to TODO. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
RE: [HACKERS] Hardwired MAXBACKENDS limit could be history
> > Conditional variables seem to be more portable > > Really? Which standard are they specified in? POSIX - they are in pthread library (eg man pthread_cond_init). For sem_init I see in man (on Solaris and AIX): ENOSYS The sem_init() function is not supported what is exactly I've got on AIX. Vadim
Re: [HACKERS] Hardwired MAXBACKENDS limit could be history
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes: >> What I'd like to look at sometime soon is using POSIX semaphores >> instead of SysV semaphores. But we need stateful semaphores, >> not signals. > Conditional variables seem to be more portable Really? Which standard are they specified in? I have no intention of removing the SysV sem support, mind you; I just think it might be good to have an alternative implementation that relies on a more modern standard ... regards, tom lane
RE: [HACKERS] Hardwired MAXBACKENDS limit could be history
> > Did you ever consider remove per-backend semaphores at all? > > We use them to sleep waiting for lock (ie when someone awake > > us by changing our semaphore) - why don't use sigpause and > > some signal? > > That'll fail if the signal arrives before the sigpause(), no? Ops, you're right. > > Semaphores are good to sync access to *shared* > > resources but it's not that case here. > > The thing we really need here is that the right thing has to happen > if the V() occurs before our P(), ie, the V() has to be remembered > so that we will fall through the P() without blocking. > > What I'd like to look at sometime soon is using POSIX semaphores > instead of SysV semaphores. But we need stateful semaphores, > not signals. Conditional variables seem to be more portable - recently I had to rewrite some program with POSIX sem developed under Solaris when porting to AIX. (BTW, OmniORB uses cond vars to simulate semaphores). Vadim
Re: [HACKERS] Hardwired MAXBACKENDS limit could be history
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes: > Did you ever consider remove per-backend semaphores at all? > We use them to sleep waiting for lock (ie when someone awake > us by changing our semaphore) - why don't use sigpause and > some signal? That'll fail if the signal arrives before the sigpause(), no? > Semaphores are good to sync access to *shared* > resources but it's not that case here. The thing we really need here is that the right thing has to happen if the V() occurs before our P(), ie, the V() has to be remembered so that we will fall through the P() without blocking. What I'd like to look at sometime soon is using POSIX semaphores instead of SysV semaphores. But we need stateful semaphores, not signals. regards, tom lane
RE: [HACKERS] Hardwired MAXBACKENDS limit could be history
> I'm not thinking about getting this done in time for 7.1, but I think > it'd be a nice cleanup for 7.2. > > Bruce, a TODO item please: > * Remove compile-time upper limit on number of backends > (MAXBACKENDS) Did you ever consider remove per-backend semaphores at all? We use them to sleep waiting for lock (ie when someone awake us by changing our semaphore) - why don't use sigpause and some signal? Semaphores are good to sync access to *shared* resources but it's not that case here. Vadim