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" which was 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 alter table 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(dot)speigle(at)jklh(dot)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(at)postgresql(dot)org

--
joe speigle