Thread: regression failure
I just got this regression failure on Windows: ================== 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 --- cheers andrew
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
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
> 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.