PostgreSQL Bugs - BUG #2033: Assertion Failure: File: "procarray.c", Line: 492

Author

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

Joel Stevenson

2005-11-09, 9:24 am

The following bug has been logged online:

Bug reference: 2033
Logged by: Joel Stevenson
Email address: joelstevenson@mac.com
PostgreSQL version: 8.1.0
Operating system: RHEL 3 update 6
Description: Assertion Failure: File: "procarray.c", Line: 492
Details:

Hi,

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)

Postgres was configured using both --enable-debug and --enable-cassert.
Full config options were:

../configure CFLAGS=-O2 -pipe --with-perl --with-openssl
--enable-thread-safety --enable-debug --enable-cassert
--with-includes=/usr/kerberos/include

Some non-default postgresql.conf params:
max_connections = 150
ssl = on
shared_buffers = 4000
work_mem = 102400
maintenance_work_mem
= 131072
max_stack_depth = 4096
commit_delay = 100
checkpoint_segments = 5
effective_cache_size
= 173015
stats_start_collecto
r = on
stats_command_string
= on
stats_block_level = on
stats_row_level = on
stats_reset_on_serve
r_start = on
autovacuum = on
autovacuum_analyze_s
cale_factor = 0.1

I've removed the 'NOWAIT' for the time being, but thought I should mention
the issue.

Thanks,
Joel

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane

2005-11-09, 11:24 am

"Joel Stevenson" <joelstevenson@mac.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 :-(

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly

Tom Lane

2005-11-09, 8:24 pm

Joel Stevenson <joelstevenson@mac.com> writes:
> This produced a bunch of core files that show the following backtrace:

> #0 0x001ea038 in ?? ()
> #1 0xbfffa4d8 in ?? ()
> #2 0xbfffa5e0 in ?? ()
> #3 0xbfffa560 in ?? ()
> #4 0x08180844 in ?? ()
> #5 0x00000005 in ?? ()
> #6 0xbfffa4e0 in ?? ()
> #7 0x00000000 in ?? ()

> I'm at a loss as to what to do about it, really; is there a hidden
> configure flag or something that could be in my environment that's
> causing the executable to be stripped?

Nondefault LDFLAGS maybe? Look at the commands that link all the
SUBSYS.o files to produce the postgres executable.

Also, on most Unixen "file /path/to/postgres" will tell the difference
between a stripped and nonstripped executable.

If "file" says that the executable isn't stripped, then the problem is
either with gdb itself or with the way you're invoking it. Could we see
a cut-and-paste of the whole terminal session with gdb, rather than just
the result of the bt part?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Tom Lane

2005-11-09, 8:24 pm

Joel Stevenson <joelstevenson@mac.com> writes:
> Thanks Tom, and apologies for the confusion; not having worked w/gdb
> before I was invoking it incorrectly. Here's what the core file
> produced from the assertion failure has for a backtrace:

OK, now that that's straightened out, there are some more things to
look at in the core file. Please try these gdb commands:

p *MyProc
p *SerializableSnapsho
t
p *CurrentTransactionS
tate

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane

2005-11-09, 8:24 pm

Joel Stevenson <joelstevenson@mac.com> writes:
> (gdb) p *CurrentTransactionS
tate
> $3 = {transactionId = 1068154, subTransactionId = 1, name = 0x0,
> savepointLevel = 0,
> state = TRANS_ABORT, blockState = TBLOCK_ABORT, nestingLevel = 1,
> curTransactionContex
t = 0x9b06a9c, curTransactionOwner = 0x9ab0294,
> childXids = 0x0, currentUser = 0, prevXactReadOnly = 0 '\0', parent = 0x0}

Ah-hah, that tells the tale: you're in an already-failed transaction,
and so there are large parts of the backend that Just Won't Work.

What is missing here, I think, is a test in exec_bind_message()
similar to what's in exec_execute_message
(): bail out early if the
transaction is aborted and the command in the portal is anything but
ROLLBACK/COMMIT/PREPARE. In this case you are trying to bind to a
portal containing a SELECT statement (the line number in pquery.c proves
this), and since you couldn't Execute that, there seems little need to
let you Bind it.

Kinda surprising this hasn't been reported before; the bug or something
close to it doubtless exists in 7.4 as well.

regards, tom lane

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

Sponsored Links