Re: pg primary key bug?

Hi,
sorry, but we have the case number 3 in with the same problem.
Also this time we do not find any linux box crash nor pg stop or restart.
The pg version is 7.4.2 on dual xeon + scsi running also RedHat 3.0 AS.
In all the cases we are running RedHat AS 3.0.
This system was running for over 12 m. without any problems.
I send also the state of the problem table (also the same) and my
question is:
Need we to stop using vacuum full for now?
And can only vacuum analyze make the same problem in pg?
As I understand the problem is in OS by making vacuum full analyze (as
Tom wrote).
We do not found any problems in OS and the ony solution we see is to
stop using vacuum full analyze.
Also we are using only jdbc to access pg. Is it possible that jdbc to
make this problem?

regards,
ivan.
serv117=# select oid, xmin, cmin, xmax, cmax, ctid, * from a_constants_str ;
oid | xmin | cmin | xmax | cmax | ctid |
constname | fid | constvalue
-----------+---------+---------+---------+---------+----------+-----------+-----+-------------
760807304 | 7357839 | 0 | 0 | 0 | (0,1) |
PARTID | 0 | SOF_79
760807305 | 7357839 | 0 | 0 | 0 | (0,2) |
AACCGRID | 0 | SOF_29
760807306 | 7357839 | 0 | 0 | 0 | (0,3) |
AKLTYPID | 0 | SOF_47
760807307 | 7357839 | 0 | 0 | 0 | (0,4) |
AOBLASTID | 0 | SOF_41
760807308 | 7357839 | 0 | 0 | 0 | (0,5) |
ANMGRID | 0 | SOF_102
760807309 | 7357839 | 0 | 0 | 0 | (0,6) |
LOCAID | 0 | SOF_112
760807310 | 7357839 | 0 | 0 | 0 | (0,7) |
AKLGRID | 0 | SOF_116
760807311 | 7357839 | 0 | 0 | 0 | (0,8) |
ADARID | 0 | SOF_33
760807314 | 7357839 | 0 | 0 | 0 | (0,11) |
ASLUID | 0 | SOF_86
760807315 | 7357839 | 0 | 0 | 0 | (0,12) |
AUSERID | 0 | SOF_28
760807318 | 7357839 | 0 | 0 | 0 | (0,15) |
ANLIZPID | 0 | SOF_100137
760807316 | 7507505 | 3 | 3 | 0 | (0,36) |
ASETUPID | 0 | SOF_4618
760807324 | 7750088 | 7766293 | 7766293 | 2 | (0,92) |
DOCID | 0 | SOF_836141
760807319 | 7740812 | 2 | 2 | 0 | (4,8) |
ANOMID | 0 | SOF_31353
760807325 | 7750088 | 19 | 19 | 0 | (4,111) |
DOCRID | 0 | SOF_2067257
760807326 | 7750088 | 41 | 41 | 7750975 | (6,27) |
DOCPLAID | 0 | SOF_44261
760807327 | 7750088 | 46 | 46 | 7750975 | (7,106) |
DOCPOGPLA | 0 | SOF_58034
760807324 | 7750088 | 7766293 | 7766293 | 1 | (9,107) |
DOCID | 0 | SOF_836141
760807313 | 7680519 | 2 | 2 | 0 | (10,3) |
NASTRF | 0 | SOF_161
760807312 | 7688072 | 2 | 2 | 0 | (10,92) |
AGRADID | 0 | SOF_804
760807324 | 7750088 | 7766293 | 7766293 | 1 | (12,18) |
DOCID | 0 | SOF_836141
760807324 | 7750088 | 7766293 | 7766293 | 1 | (13,94) |
DOCID | 0 | SOF_836141
760807324 | 7750088 | 7766293 | 7766293 | 1 | (15,45) |
DOCID | 0 | SOF_836141
760807324 | 7750088 | 7766293 | 7766293 | 1 | (17,4) |
DOCID | 0 | SOF_836141
760807324 | 7750088 | 7766293 | 7766293 | 1 | (18,80) |
DOCID | 0 | SOF_836141
760807324 | 7750088 | 7766293 | 7766293 | 1 | (20,31) |
DOCID | 0 | SOF_836141
760807324 | 7750088 | 7766293 | 7766293 | 1 | (21,109) |
DOCID | 0 | SOF_836141
760807324 | 7750088 | 7766293 | 7766293 | 1 | (23,58) |
DOCID | 0 | SOF_836141
760807324 | 7750088 | 7766293 | 7766293 | 1 | (25,9) |
DOCID | 0 | SOF_836141
760807324 | 7750088 | 7766293 | 7766293 | 1 | (26,85) |
DOCID | 0 | SOF_836141
760807324 | 7750088 | 7766293 | 7766293 | 1 | (28,36) |
DOCID | 0 | SOF_836141
760807324 | 7750088 | 7766293 | 7766293 | 1 | (29,114) |
DOCID | 0 | SOF_836141
760807317 | 7702028 | 2 | 2 | 0 | (51,41) |
AMITAID | 0 | SOF_345
760807320 | 7702064 | 2 | 2 | 0 | (51,42) |
ATRANSID | 0 | SOF_458
760807321 | 7707993 | 2 | 2 | 0 | (57,8) |
TDOCID | 0 | SOF_546
760807323 | 7753774 | 3 | 3 | 0 | (59,7) |
AKLIID | 0 | SOF_22695
760807322 | 7707993 | 2385 | 2385 | 0 | (59,95) |
TDOCRID | 0 | SOF_105930
(37 rows)

serv117=# \d a_constants_str
Table "public.a_constants_str"
Column | Type | Modifiers
------------+-----------------------+-----------
constname | character varying(30) | not null
fid | integer | not null
constvalue | character varying(30) |
Indexes:
"a_constants_str_pkey" primary key, btree (constname, fid)

Tom Lane wrote:

>pginfo <pginfo(at)t1(dot)unisoftbg(dot)com> writes:
>
>
>>Will upgrade to 8.0 solve this type of problems ?
>>
>>
>
>The problem is probably not Postgres' fault at all. I'm wondering about
>disks with write cacheing enabled. And you didn't turn off fsync,
>I trust?
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 8: explain analyze is your friend
>
>
>
>