|
1 | | -$Header: /cvsroot/pgsql/src/backend/storage/lmgr/README,v 1.6 2001/01/22 22:30:06 tgl Exp $ |
| 1 | +$Header: /cvsroot/pgsql/src/backend/storage/lmgr/README,v 1.7 2001/01/25 03:31:16 tgl Exp $ |
2 | 2 |
|
3 | 3 | There are two fundamental lock structures: the per-lockable-object LOCK |
4 | 4 | struct, and the per-lock-holder HOLDER struct. A LOCK object exists |
@@ -373,7 +373,8 @@ time with "C before B", which won't move C far enough up. So we look for |
373 | 373 | soft edges outgoing from C starting at the front of the wait queue. |
374 | 374 |
|
375 | 375 | 5. The working data structures needed by the deadlock detection code can |
376 | | -be proven not to need more than MAXBACKENDS entries. Therefore the |
377 | | -working storage can be statically allocated instead of depending on |
378 | | -palloc(). This is a good thing, since if the deadlock detector could |
379 | | -fail for extraneous reasons, all the above safety proofs fall down. |
| 376 | +be limited to numbers of entries computed from MaxBackends. Therefore, |
| 377 | +we can allocate the worst-case space needed during backend startup. |
| 378 | +This seems a safer approach than trying to allocate workspace on the fly; |
| 379 | +we don't want to risk having the deadlock detector run out of memory, |
| 380 | +else we really have no guarantees at all that deadlock will be detected. |