Re: [PATCHES] Minor fix in lwlock.c

2005-04-07 Thread Tom Lane
"Qingqing Zhou" <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes >> Maybe we *should* make it a PANIC. Thoughts? > Reasonable. Since this should *never* happen. Once happened, that's means we > have a serious bug in our design/coding. Plan C would be something like if

Re: [PATCHES] Minor fix in lwlock.c

2005-04-07 Thread Qingqing Zhou
"Tom Lane" <[EMAIL PROTECTED]> writes > > Maybe we *should* make it a PANIC. Thoughts? > Reasonable. Since this should *never* happen. Once happened, that's means we have a serious bug in our design/coding. Regards, Qingqing ---(end of broadcast)--

Re: [PATCHES] Minor fix in lwlock.c

2005-04-07 Thread Tom Lane
"Qingqing Zhou" <[EMAIL PROTECTED]> writes: > Another alternative might use PG_TRY/PG_CATCH to make sure that the > semaphore is released. But seems this costs too much ... I agree. LWLockAcquire is a hot-spot already. Maybe we *should* make it a PANIC. Thoughts? regard

Re: [PATCHES] Minor fix in lwlock.c

2005-04-07 Thread Qingqing Zhou
"Tom Lane" <[EMAIL PROTECTED]> writes> > The alternative would be to move the Unlock loop in front of the > addition of the LWLock to held_lwlocks[], but I think that cure > is probably worse than the disease --- the chance of an error during > Unlock seems nonzero. > Another alternative might us

Re: [PATCHES] Minor fix in lwlock.c

2005-04-07 Thread Tom Lane
"Qingqing Zhou" <[EMAIL PROTECTED]> writes: > I guess the problem is here: > /* > * Fix the process wait semaphore's count for any absorbed wakeups. > */ > while (extraWaits-- > 0) > PGSemaphoreUnlock(&proc->sem); Mmm. Could be a problem, but the chances of having extraWaits>0 is really

Re: [PATCHES] Minor fix in lwlock.c

2005-04-07 Thread Qingqing Zhou
"Tom Lane" <[EMAIL PROTECTED]> writes > I don't see any reason to think we'd be unable to recover normally from such a > bug --- do you? > I guess the problem is here: /* * Fix the process wait semaphore's count for any absorbed wakeups. */ while (extraWaits-- > 0) PGSemaphoreUnlock(&pro

Re: [PATCHES] Minor fix in lwlock.c

2005-04-07 Thread Tom Lane
"Qingqing Zhou" <[EMAIL PROTECTED]> writes: > The chance that num_held_lwlocks is beyond MAX_SIMUL_LWLOCKS is similar to > the chance that failed to grasp a spinlock in 1 minute, so they should be > treated in the same way. This is mainly to prevent programming error (e.g., > forget to release the

[PATCHES] Minor fix in lwlock.c

2005-04-07 Thread Qingqing Zhou
The chance that num_held_lwlocks is beyond MAX_SIMUL_LWLOCKS is similar to the chance that failed to grasp a spinlock in 1 minute, so they should be treated in the same way. This is mainly to prevent programming error (e.g., forget to release the LWLocks). Regards, Qingqing --- Index: lwlock.c =

Re: [PATCHES] fork_process() for pgstat

2005-04-07 Thread Neil Conway
Neil Conway wrote: Much to my chagrin, I recently noticed that I forgot to convert the pgstat fork() code to use fork_process() when I applied the original fork_process() patch a few months ago. This patch does that. Applied. -Neil ---(end of broadcast)

Re: [PATCHES] add_missing_from = false

2005-04-07 Thread Neil Conway
Neil Conway wrote: Now that DELETE has a USING clause, we should be able to make add_missing_from=false the default in 8.1; the attached patch implements this and updates the documentation. Applied. -Neil ---(end of broadcast)--- TIP 7: don't forget

Re: [GENERAL] [PATCHES] A way to let Vacuum warn if FSM settings are

2005-04-07 Thread Bruce Momjian
Ron Mayer wrote: > Tom Lane wrote: > > Bruce Momjian writes: > >>I never heard any discussion on whether this should be backpatched to > >>8.0.X. Should it? > > I personally think it should _not_ be backpatched. Since it > doesn't fix any bugs, it's not really the kind of thing I > would expect

Re: [GENERAL] [PATCHES] A way to let Vacuum warn if FSM settings

2005-04-07 Thread Ron Mayer
Tom Lane wrote: Bruce Momjian writes: I never heard any discussion on whether this should be backpatched to 8.0.X. Should it? I personally think it should _not_ be backpatched. Since it doesn't fix any bugs, it's not really the kind of thing I would expect to be backpatched. I'm not inclined to

Re: [GENERAL] [PATCHES] A way to let Vacuum warn if FSM settings are low. [final?]

2005-04-07 Thread Tom Lane
Bruce Momjian writes: > I never heard any discussion on whether this should be backpatched to > 8.0.X. Should it? I'm not inclined to throw it in at the last minute, as it's not been through any testing and I'm not sure the behavior has really been agreed on anyway. (The diff you cite starts fr

Re: [GENERAL] [PATCHES] A way to let Vacuum warn if FSM settings are

2005-04-07 Thread Bruce Momjian
I never heard any discussion on whether this should be backpatched to 8.0.X. Should it? --- pgman wrote: > Simon Riggs wrote: > > On Mon, 2005-03-14 at 01:40 -0500, Tom Lane wrote: > > > Bruce Momjian writes: > > > > Ron M

[PATCHES] fork_process() for pgstat

2005-04-07 Thread Neil Conway
Much to my chagrin, I recently noticed that I forgot to convert the pgstat fork() code to use fork_process() when I applied the original fork_process() patch a few months ago. This patch does that. Barring any objections, I'll apply this tomorrow. -Neil Index: src/backend/postmaster/pgstat.c ===

[PATCHES] add_missing_from = false

2005-04-07 Thread Neil Conway
Now that DELETE has a USING clause, we should be able to make add_missing_from=false the default in 8.1; the attached patch implements this and updates the documentation. Barring any objections, I'll apply this tomorrow. -Neil Index: doc/src/sgml/runtime.sgml