Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

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


  • From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
  • To: Joel Stevenson <joelstevenson(at)mac(dot)com>
  • Cc: pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
  • Subject: Re: BUG #2033: Assertion Failure: File: "procarray.c", Line: 492
  • Date: Wed, 09 Nov 2005 15:53:18 -0500
  • Message-id: <19162.1131569598@sss.pgh.pa.us> <text/plain>

Joel Stevenson <joelstevenson(at)mac(dot)com> writes:
> (gdb) p *CurrentTransactionState
> $3 = {transactionId = 1068154, subTransactionId = 1, name = 0x0, 
> savepointLevel = 0,
>    state = TRANS_ABORT, blockState = TBLOCK_ABORT, nestingLevel = 1,
>    curTransactionContext = 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



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group