Return-Path: pg_adm@postgres.berkeley.edu Received: by postgres.Berkeley.EDU (5.61/1.29) id AA11124; Tue, 18 Aug 92 11:22:46 -0700 Date: Tue, 18 Aug 92 11:22:46 -0700 Message-Id: <9208181822.AA11124@postgres.Berkeley.EDU> From: Sean Levy Subject: more info on nastiness To: postgres@postgres.berkeley.edu Sender: pg_adm@postgres.berkeley.edu 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: snl+@cmu.edu, Phone: +1 412 268 5221, Fax: +1 412 268 5229