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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

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)

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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



---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

"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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

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


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)