Re: BUG #2033: Assertion Failure: File: "procarray.c",

>"Joel Stevenson" <joelstevenson(at)mac(dot)com> writes:
>> I'm running into an Assertion failure this morning w/8.1.0. I believe it is
>> related to using the NOWAIT flag. Here is the log message:
>
>> TRAP: FailedAssertion("!(serializable ? !((MyProc->xmin) != ((TransactionId)
>> 0))
>> : ((MyProc->xmin) != ((TransactionId) 0)))", File: "procarray.c", Line:
>> 492)
>
>With no stack trace, and no information about how to reproduce the
>error, I'm afraid this report is just about useless :-(

gdb's 'bt' on one of the core files produces:

#0 0x00138eff in ?? ()
#1 0x0017ec8d in ?? ()
#2 0x00246cd8 in ?? ()
#3 0x00000000 in ?? ()

the backtrace in various other of the 17 core files looks exactly the same.

I am not a C programmer but am happy to try to dig up any information
I can from the core files, but will need instruction from someone
wiser in the ways of gdb than I. :)

My second email provided more detail about what PG is being used for
and what was happening when the assertion failure occurred. A
further description:

* There is one process which is inserting work units into a work_queue table.
The rate of insertion varies but can become very high.

* There are between zero and 100 other processes which select from the
work_queue table using SELECT ... LIMIT 1 FOR UPDATE NOWAIT. Because of the
where clause conditions and the LIMIT 1, these processes can and do contend
for the same rows in the table. When a row is retrieved it is immediately
updated as 'claimed'.

* Without the NOWAIT flag, the contending processes operate as
expected: either
retrieving a row or waiting on a lock briefly and not retrieving a row
because the first lock resulted in an update causing the match to become
invalid.

* At the time of the assertion failure, there where approximately 20
work_queue
consumer processes running and the work_queue provider process was actively
inserting new data into the table.

Here are some more log lines at the error point:

<snip>
2005-11-09 07:00:06 PST 19681 ERROR: 55P03: could not obtain lock on
row in rel
ation "WORK_QUEUE"
2005-11-09 07:00:06 PST 19681 LOCATION: heap_lock_tuple, heapam.c:2157
2005-11-09 07:00:06 PST 19681 STATEMENT: SELECT ID, UNIT
FROM WORK_QUEUE
WHERE
blah...blah...blah
LIMIT 1
FOR UPDATE
NOWAIT
TRAP: FailedAssertion("!(serializable ? !((MyProc->xmin) !=
((TransactionId) 0))
: ((MyProc->xmin) != ((TransactionId) 0)))", File: "procarray.c", Line: 492)
2005-11-09 07:00:06 PST 14093 LOG: 00000: server process (PID 19681)
was termin
ated by signal 6
2005-11-09 07:00:06 PST 14093 LOCATION: LogChildExit, postmaster.c:2426
2005-11-09 07:00:06 PST 14093 LOG: 00000: terminating any other
active server p
rocesses
2005-11-09 07:00:06 PST 14093 LOCATION: HandleChildCrash, postmaster.c:2307
2005-11-09 07:00:06 PST 20323 WARNING: 57P02: terminating connection
because of
crash of another server process
</snip>

the ERROR: 55P03 seems expected given the description of how NOWAIT operates.

Let me know if I can provide more information.

-Joel