Skip site navigation (1) Skip section navigation (2)

Re: Minor fix in lwlock.c

From: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
To: pgsql-patches(at)postgresql(dot)org
Subject: Re: Minor fix in lwlock.c
Date: 2005-04-08 07:58:52
Message-ID: d35dnd$n6j$ (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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)

/* 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.


In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2005-04-08 14:04:19
Subject: Re: Minor fix in lwlock.c
Previous:From: Tom LaneDate: 2005-04-08 06:39:15
Subject: Re: Minor fix in lwlock.c

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group