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

Re: [HACKERS] initdb problem

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: emkxp01(at)mtcc(dot)demon(dot)co(dot)uk
Cc: hackers(at)postgreSQL(dot)org (PostgreSQL-development)
Subject: Re: [HACKERS] initdb problem
Date: 1998-08-24 19:18:28
Message-ID: 199808241918.PAA09838@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> Bruce,
> 
> It does not seem to be an initdb problem per se, as the initdb
> proceeds normally and I end up with a database that works to some
> extent.
> 
> If you have seen my recent posts and backtraces you will see that,
> after initdb'ing, I connect to the template1 database and do a
> "select * from pg_user;" is get an error.
> 
> template1=> select * from pg_user;
> ERROR:  Relation pg_user does not have attribute usename
> template1=> 
> 
> If I attempt to create a table I get a core dump.
> 
> It smells of an alignment problem (I'm on SPARC/Linux) as the
> error is in a system call memmove() and the library call where
> it bombs is _wordcopy_fwd_aligned ().

OK.

I have fixed the bootstrap process so it properly assignes attalign
values.  It was not need with single-key indexes, but is needed now.

Also, I found many cases where system columns where missing
pg_attribute.attalign values.  The values where ' '.   The system has no
idea what to do with such a value.

Would someone check a running 6.3.2 system and let me know if there are
any blank attalign values?  It think you will find that there are.  The
current patch fixes that.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-08-24 19:59:48
Subject: initdb problems
Previous:From: Florian WunderlichDate: 1998-08-24 17:17:23
Subject: Re: [GENERAL] DELETE statement KILL backend <AGAIN>

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group