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

"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, Pennsylvania 19026