Re: Minor fix in lwlock.c - Mailing list pgsql-patches

From Qingqing Zhou
Subject Re: Minor fix in lwlock.c
Date
Msg-id d35dnd$n6j$1@news.hub.org
Whole thread Raw
In response to Minor fix in lwlock.c  ("Qingqing Zhou" <zhouqq@cs.toronto.edu>)
Responses Re: Minor fix in lwlock.c
Re: Minor fix in lwlock.c
List pgsql-patches
"Tom Lane" <tgl@sss.pgh.pa.us> writes
> Plan C would be something like
>
> if (num_held_lwlocks >= MAX_SIMUL_LWLOCKS)
> {
> release the acquired lock;
> elog(ERROR, "too many LWLocks taken");
> }
>
> But we couldn't just call LWLockRelease, since it expects the lock to
> be recorded in held_lwlocks[].  We'd have to duplicate a lot of code,
> or split LWLockRelease into multiple routines, neither of which seem
> attractive answers considering that this must be a can't-happen
> case anyway.

We can reserve some LWLocks for elog(FATAL) since the shmem_exit() would
need it (Seems elog(ERROR) does not need it). So even if ERROR is upgraded
to FATAL in some cases (e.g., PGSemaphoreUnlock() fails), we could still
exit gracefully. The code will be like this:

---
/* Unlock semaphores first */
while (extraWaits-- > 0)
    PGSemaphoreUnlock(&proc->sem);

/* Add the lock into my list then.
 * If a process is in exiting status, it could use the reserved lwlocks
 */
reserved = proc_exit_inprogress? 0 : NUM_RESERVED_LWLOCKS;
if (num_held_lwlocks >= MAX_SIMUL_LWLOCKS - reserved)
    elog(ERROR, "too many LWLocks taken");
held_lwlocks[num_held_lwlocks++] = lockid;
---

Since this is a should-not-happen case, so the fix could be reserved for
tomorrow when we need PG to grasp more LWLocks than now.

Regards,
Qingqing



pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Minor fix in lwlock.c
Next
From: Tom Lane
Date:
Subject: Re: Minor fix in lwlock.c