From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Reducing sema usage (was Postmaster dies with many child processes) |
Date: | 1999-01-31 01:42:56 |
Message-ID: | 199901310142.UAA01549@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> A considerably more straightforward approach is just to forget about
> incremental allocation of semaphores and grab all we could need at
> postmaster startup. ("OK, Mac, you told me to allow up to N backends?
> Fine, I'm going to grab N semaphores at startup, and if I can't get them
> I won't play.") This would force the DB admin to either reconfigure the
> kernel or reduce MaxBackendId to something the kernel can support right
> off the bat, rather than allowing the problem to lurk undetected until
> too many clients are started simultaneously. (Note there are still
> potential gotchas with running out of processes, swap space, or file
> table slots, so we wouldn't have really guaranteed that N backends can
> be started safely.)
>
> If we make MaxBackendId settable from a postmaster command-line switch
> then this second approach is probably not too inconvenient, though it
> surely isn't pretty.
>
> Any thoughts about which way to jump? I'm sort of inclined to take
> the simpler approach myself...
Semaphore are hard enough without overloading them. I say just gram
them on startup. They are cheap. Many databases use semaphores for
every row/page they lock, and boy that can be a lot of semaphores. We
are only getting a few.
--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-01-31 01:45:23 | Re: [HACKERS] Re: Reducing sema usage (was Postmaster dies with many child processes) |
Previous Message | Bruce Momjian | 1999-01-31 01:24:49 | Re: AW: [HACKERS] Another TEMP table trick |