SEO

I got this assertion failure today:

TRAP: FailedAssertion("!(new_max_attr >= oldrel->max_attr)", File: "prepunion.c", Line: 1292)

From running something like this:

postgres=# create table foo (i integer);
CREATE TABLE
postgres=# alter table foo add j integer;
ALTER TABLE
postgres=# alter table foo drop j;
ALTER TABLE
postgres=# create table foo2 () inherits (foo);
CREATE TABLE
postgres=# explain analyze select * from foo;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.


I think there isn't actually a bug here except that the assertions are
incorrect. Everything else in the function looks ok.

diff -u -r1.142 prepunion.c
--- prepunion.c 11 Jun 2007 01:16:23 -0000 1.142
+++ prepunion.c 12 Jul 2007 14:13:11 -0000
@@ -1288,8 +1288,6 @@
ListCell *lm;

/* Create empty result array */
- Assert(new_min_attr <= oldrel->min_attr);
- Assert(new_max_attr >= oldrel->max_attr);
new_attr_needed = (Relids *)
palloc0((new_max_attr - new_min_attr + 1) * sizeof(Relids));
/* Process user attributes, with appropriate attno mapping */




--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Gregory Stark <stark@enterprisedb.com> writes:
> I got this assertion failure today:

> postgres=# create table foo (i integer);
> CREATE TABLE
> postgres=# alter table foo add j integer;
> ALTER TABLE
> postgres=# alter table foo drop j;
> ALTER TABLE
> postgres=# create table foo2 () inherits (foo);
> CREATE TABLE
> postgres=# explain analyze select * from foo;
> server closed the connection unexpectedly

Nifty.

> I think there isn't actually a bug here except that the assertions are
> incorrect. Everything else in the function looks ok.

In the light of this example, the Assert on new_max_attr is clearly
wrong. It always was redundant with the ones inside the first loop anyway.
I think the Assert on new_min_attr is still OK though, and in fact
necessary to protect against an array bounds violation in the second
loop. That Assert is essentially saying that "if the parent table has
OIDs then the child must too", which we do enforce.

Will patch in HEAD and 8.2 --- this code doesn't exist before 8.2.

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