regression failure

Andrew Dunstan <andrew@dunslane.net> writes:

I just got this regression failure on Windows:

If it's repeatable, could you get a debugger stack trace from the
errfinish call? Or even just add "\set VERBOSITY verbose" to the
test script so we can tell which of the many instances of that
string this is ...

regards, tom lane

On Thu, Jun 23, 2005 at 11:08:55AM -0400, Andrew Dunstan wrote:

I just got this regression failure on Windows:

Maybe it has to do with being unable to drop the relcache file?

================== pgsql.2220/src/test/regress/regression.diffs 
===================
*** ./expected/prepared_xacts.out   Thu Jun 23 10:20:28 2005
--- ./results/prepared_xacts.out    Thu Jun 23 10:45:06 2005
***************
*** 179,189 ****
-- Commit table creation
COMMIT PREPARED 'regress-one';
\d pxtest2
!     Table "public.pxtest2"
!  Column |  Type   | Modifiers
! --------+---------+-----------
!  a      | integer |
!
SELECT * FROM pxtest2;
a
---
--- 179,185 ----
-- Commit table creation
COMMIT PREPARED 'regress-one';
\d pxtest2
! ERROR:  cache lookup failed for relation 27228
SELECT * FROM pxtest2;
a
---

--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"El Maquinismo fue proscrito so pena de cosquilleo hasta la muerte"
(Ijon Tichy en Viajes, Stanislaw Lem)

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

I just got this regression failure on Windows:

If it's repeatable, could you get a debugger stack trace from the
errfinish call? Or even just add "\set VERBOSITY verbose" to the
test script so we can tell which of the many instances of that
string this is ...

namespace.c::RelationIsVisible - line 319

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

I just got this regression failure on Windows:

namespace.c::RelationIsVisible - line 319

Hmph. No obvious reason why that would be platform-dependent. Is it
completely repeatable for you? (You might try the advice I just gave
Dave Cramer: make distclean and rebuild to ensure you've got fully
consistent bits ...)

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

I just got this regression failure on Windows:

namespace.c::RelationIsVisible - line 319

Hmph. No obvious reason why that would be platform-dependent. Is it
completely repeatable for you? (You might try the advice I just gave
Dave Cramer: make distclean and rebuild to ensure you've got fully
consistent bits ...)

Yes, I always do that with troubles. This was a completely fresh
checkout from CVS.

It's not 100% repeatable, but I have seen it about 60% of the time over
8 or 10 runs.

cheers

andrew

Andrew Dunstan wrote:

It's not 100% repeatable, but I have seen it about 60% of the time
over 8 or 10 runs.

But now I can't reproduce it at all. :-(

cheers

andrew

"Tom Lane" <tgl@sss.pgh.pa.us> writes

Hmph. No obvious reason why that would be platform-dependent. Is it
completely repeatable for you? (You might try the advice I just gave
Dave Cramer: make distclean and rebuild to ensure you've got fully
consistent bits ...)

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

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.

Regards,
Qingqing

"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 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

That might be explained by this 8.0.2/7.4.8 fix:

<snip>

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?

We skipped 8.0.2 and went to 8.0.3 near the beginning of the month.

We were getting a WARNING indicating the lock table was corrupted. It
has never crashed, and I've not seen any odd locking issues as a result,
but we get the warning nonetheless. I believe the warning was recently
changed to a panic for 8.1.

Anyway, no, I've not seen that problem since the beginning of the month
but I also don't recall aborting schema alterations recently either.