The following bug has been logged online:

Bug reference: 2033
Logged by: Joel Stevenson
Email address: joelstevenson (AT) mac (DOT) 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_collector = on
stats_command_string = on
stats_block_level = on
stats_row_level = on
stats_reset_on_server_start = on
autovacuum = on
autovacuum_analyze_scale_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

"Joel Stevenson" <joelstevenson (AT) mac (DOT) com> writes:
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 (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Joel Stevenson <joelstevenson (AT) mac (DOT) com> writes:
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

Joel Stevenson <joelstevenson (AT) mac (DOT) com> writes:
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 *SerializableSnapshot
p *CurrentTransactionState

regards, tom lane

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

http://archives.postgresql.org

Joel Stevenson <joelstevenson (AT) mac (DOT) com> writes:
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