Re: regression failure

"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> I once noticed that there was something weird of Lock in win32 pg8.0.1. If
> you have many connections work concurrently intensively(say contrib/pgbench)
> and do fast shutdown in the middle, you will see an assertation failure
> here:

> if (lock->nRequested == 0)
> {
> /*
> * We've just released the last lock, so garbage-collect the lock
> * object.
> */
> Assert(SHMQueueEmpty(&(lock->procLocks))); >>> here

That might be explained by this 8.0.2/7.4.8 fix:

2005-03-01 16:14 tgl

* src/backend/storage/lmgr/: lock.c (REL7_4_STABLE), lock.c
(REL8_0_STABLE), lock.c: Release proclock immediately in
RemoveFromWaitQueue() if it represents no held locks. This
maintains the invariant that proclocks are present only for procs
that are holding or awaiting a lock; when this is not true,
LockRelease will fail. Per report from Stephen Clouse.

I just spent some time doing "pg_ctl stop -m fast" against CVS tip while
pg_bench was running, and couldn't reproduce a problem --- not that that
should give anyone great confidence.

This does bring up a question for Rod: have you installed a release
including the above fix, and if so have you noticed the
crash-after-SIGTERM problem since then?

> The target lock is always 376(XactLockTableId) but there is no obvious
> reason why this could happen. Now we removed 376, so everything looks ok.

Well, that observation comforts me not at all, because the transaction
locks are certainly still there; there's just been a trivial change in
how their locktags are represented. If there's a bug, this change did
not fix it.

regards, tom lane