Re: simple update closes connection. why?

no, but perhaps I will.  but since there's only this one corrupted table, it was trying to add a third column "uname"
whichwas where it went bad. It might have been this command 

alter table calling add uname character varying(30) not null default 'joe';  Or, maybe I am confused and it didnt' like
altertable calling alter column uname set not null; 

Thanks for helping out!

All my commands were:

\d calling;
alter table calling add uname character varying(30) not null default 'joe';
alter table calling add uname character varying(30) not null;
alter table calling add uname character varying(30);
alter table calling uname character varying(30) set not null;
alter table calling modify uname character varying(30) set not null;
alter table calling alter column uname character varying(30) set not null;
alter table calling alter column uname set not null;
update calling set uname='joe';
\q
update calling set uname='joe';
\q
\dt
\d calling;
select * from calling limit 5;
update calling set uname='joe';
\q
update calling set uname='joe';
\q
update calling set uname='joe';
\q
select count(*) from calling;
\d calling;
\q
\c calling;
\dt


On Sun, Feb 01, 2004 at 04:35:14PM -0500, Tom Lane wrote:
> joseph speigle <joe.speigle@jklh.us> writes:
> > okay.  I"m making progress here.  :)   I want to know if I should just delete the oid that's too very large?
> > because, I can issue a select up to row 1100.  So, Select * from calling limit 1100 returns all rows, whereas
> > select * from calling limit 1101 kills the process.
>
> Okay, so you have a corrupted tuple --- from the evidence so far I'd
> guess that the length word of the first column in that row is clobbered.
> The wacky OIDs in some of the other rows look like data corruption too.
>
> At this point my thoughts are heading in the direction of hardware
> problems.  Have you tried running any memory or disk diagnostics?
> memtest86 and badblocks seem to be the most widely used tests.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

--
joe speigle