Subject: more info on nastiness

From: Sean Levy <[email-masked]>
Date: Tue, 18 Aug 92 11:22:46 -0700

Welp, I tried several things, including dumping out my tables and
massaging them offline with join(1) to get rid of all the objects that
have been added by the user I alluded to; I the loaded in those tables
into a fresh db (i.e. cd ~postgres;rm -rf data;initdb;createdb;monitor
-c "create ...." -- REAL fresh :-) and, voialla, I got the same error.
Very strange. Next, I moved over to my trusty sun4 and, after
"freshening" the db (same seq as above), loaded in the big tables (with
user's objects). This time, the backend dumped core. Here's a traceback

program terminated by signal BUS (alignment error)
(dbx) where
ExecHashOverflowInsert() at 0x1f630
ExecHashTableInsert() at 0x1f38c
ExecHash() at 0x1eca8
ExecProcNode() at 0x1b8b4
ExecHashJoin() at 0x1fcd0
ExecProcNode() at 0x1b8c4
ExecNestLoop() at 0x22fd8
ExecProcNode() at 0x1b854
ExecutePlan() at 0x1af98
ExecMain() at 0x1ab70
PerformPortalFetch() at 0x136b4
ProcessUtility() at 0x72c34
pg_eval_dest() at 0x6fa48
pg_eval() at 0x6f6b0
PostgresMain() at 0x70ee4
main() at 0x3882c

Yuck. Does *this* ring any bells? (V3R1, remember); it vaguely did for
me, but I don't remember if the error was V3R1-specific or made its way
into V4 too. Okay, so now I want to zero out the db and try loading in
the tables sans what I thought were the offending objects. I thought
maybe my extreme method of zeroing it out wasn't necessary now, so I ran
the backend directly and did "delete tablename" and got unending streams
of the following messages

NOTICE:Aug 18 13:50:11:AbortTransaction and not in in-progress state
WARN:Aug 18 13:50:11:out of free buffers: time to abort !

        AbortCurrentTransaction() at Tue Aug 18 13:50:11 1992

from the backend. ^C and back to the old but trusty method (rm -rf ....).

Zo. All of a sudden, nothing workee. Of course, my suposition that the
problem was somewhere in the (thousands of) new objects added by the
user is probably wrong. Still, this don't seem right. I'm zapping the
whole db and starting from scratch, something I *really* don't want to
ever have to do, since I'm (planning on?) putting my application into
beta test locally, and we all need to share the same rdbms. I can have a
high degree of concurrency, that is, many user's connecting to postgres
at the same time; is this what caused the problem? (I'm the only one
doing it now). Should I switch to V4R0, buggy though it may be?

TIA,
				-- Sean
--
Sean Levy, n-dim Group, EDRC, CMU, 5000 Forbes Ave, PGH, PA 15213
Email: [email-masked], Phone: +1 412 268 5221, Fax: +1 412 268 5229

---

From: [email-masked]
Date: Tue, 18 Aug 92 18:06:33 -0700

> ExecHashTableInsert() at 0x1f38c
...

> of the following messages

I just fixed this bug recently.  Someone forgot to LONGALIGN after doing
pointer/constant arithmetic in ExecHashOverflowInsert().

> from the backend. ^C and back to the old but trusty method (rm -rf ....).

This is related to the many buffer leaks that were plugged as of v4.
Postgres used to pin buffer pool buffers and never unpin them which caused
the backend to eventually exhaust all of the free buffers.  It looks like
when it tries to abort the xact, the abort processing also tries to acquire
a free buffer and you get this endless recursion (reminds me of a bad
episode of star trek).

> doing it now). Should I switch to V4R0, buggy though it may be?

I would strongly recommend waiting for 4.0.1 before attempting this.  3.1
has quite a few corruption problems that were directly related to running
multiple users.

Jeff Meredith
[email-masked]