Обсуждение: 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)
regards, tom lane
> 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
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> 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
> > 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
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> 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
> > 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
> 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 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