Re: regression failure - Mailing list pgsql-hackers

From Tom Lane
Subject Re: regression failure
Date
Msg-id 21889.1119582466@sss.pgh.pa.us
Whole thread Raw
In response to Re: regression failure  ("Qingqing Zhou" <zhouqq@cs.toronto.edu>)
Responses Re: regression failure
List pgsql-hackers
"Qingqing Zhou" <zhouqq@cs.toronto.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
inRemoveFromWaitQueue()if it represents no held locks.  Thismaintains the invariant that proclocks are present only for
procsthatare 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


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: [PATCHES] EUC_JP and SJIS conversion improvement
Next
From: Rod Taylor
Date:
Subject: Re: regression failure