Re: simple update closes connection. why? - Mailing list pgsql-novice

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.

Here is what i get for the select you asked for:
calling=# select * from pg_attribute where attnum > 0 and attrelid = 'calling'::regclass;
-[ RECORD 1 ]-+------------
attrelid      | 577720
attname       | filename
atttypid      | 1043
attstattarget | -1
attlen        | -1
attnum        | 1
attndims      | 0
attcacheoff   | -1
atttypmod     | 44
attbyval      | f
attstorage    | x
attisset      | f
attalign      | i
attnotnull    | f
atthasdef     | f
attisdropped  | f
attislocal    | t
attinhcount   | 0
-[ RECORD 2 ]-+------------
attrelid      | 577720
attname       | description
atttypid      | 1043
attstattarget | -1
attlen        | -1
attnum        | 2
attndims      | 0
attcacheoff   | -1
atttypmod     | 184
attbyval      | f
attstorage    | x
attisset      | f
attalign      | i
attnotnull    | f
atthasdef     | f
attisdropped  | f
attislocal    | t
attinhcount   | 0
-[ RECORD 3 ]-+------------
attrelid      | 577720
attname       | uname
atttypid      | 1043
attstattarget | -1
attlen        | -1
attnum        | 3
attndims      | 0
attcacheoff   | -1
atttypmod     | 34
attbyval      | f
attstorage    | x
attisset      | f
attalign      | i
attnotnull    | f
atthasdef     | f
attisdropped  | f
attislocal    | t
attinhcount   | 0


and here is also something intersting

calling=# select oid from calling;

snip
.....
    583116
     583117
     583118
     583119
     583120
     584227
 2617245723
     588066
     588067
     578306
     578307
     578310
     588068
...... snip

( so thinking I can try to get where > 584227...)
calling=# select oid from calling where oid > 584227;
    oid
------------
 1342255253
     588066
     588067
     588068
     588069
     588090
     588091
     588093
     588094
     596284
     596285
     596286
     596287

snip
..................................
(it's a moving target!)
calling=# select oid from calling where oid > 584227;
-[ RECORD 1 ]---
oid | 1006632986
-[ RECORD 2 ]---
oid | 588066
-[ RECORD 3 ]---
oid | 588067
-[ RECORD 4 ]---

calling=# select * from pg_class where relname='calling';
-[ RECORD 1 ]--+--------------------------------------------------
relname        | calling
relnamespace   | 2200
reltype        | 577721
relowner       | 110
relam          | 0
relfilenode    | 577720
relpages       | 159
reltuples      | 1685
reltoastrelid  | 0
reltoastidxid  | 0
relhasindex    | t
relisshared    | f
relkind        | r
relnatts       | 3
relchecks      | 0
reltriggers    | 0
relukeys       | 0
relfkeys       | 0
relrefs        | 0
relhasoids     | t
relhaspkey     | f
relhasrules    | f
relhassubclass | f
relacl         | {=,joe=arwdRxt,perlcalling=arwdRxt,perl_user=arwdRxt}

calling=# select count(*) from calling;
-[ RECORD 1 ]
count | 1820

calling=#

On Sun, Feb 01, 2004 at 12:02:50PM -0500, Tom Lane wrote:
> joseph speigle <joe.speigle@jklh.us> writes:
> > i had altered the table when it was okay with the following sequence
>
> > alter table calling add column uname character varying(20);
> >  alter table calling alter column uname set not null;
> > said I couldn't do that because there were null values in it, so that's when i tried the
> > update calling set uname='joe';
> > and got errors.
>
> Hmm.  That's interesting and possibly relevant, but it can't be the
> whole story --- people have been doing that for years.  What else can
> you tell us about the history of this table?
>
> > (gdb) bt
> > #0  0x0806b854 in nocachegetattr (tuple=0x82f5b78, attnum=1, tupleDesc=0x406f23a0, isnull=0xbfffe9d3 "") at
heaptuple.c:349
>
> I'm beginning to think you must have corruption in the system catalogs,
> because there's no way that control should have reached that line for
> this table, seeing that all the columns are variable-width.  Could we
> see the output of
> select * from pg_attribute where attnum > 0 and attrelid = 'calling'::regclass;
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings

--
joe speigle