I wrote:
> Does that index contain any sensitive data, and if not could I trouble
> you for a copy? I'm still not clear on the mechanism by which the
> indexes got corrupted like this.
Oh, never mind ... I've sussed it.
nbtxlog.c's forget_matching_split() assumes it can look into the page
that w
"Peter Brant" <[EMAIL PROTECTED]> writes:
> (a bunch of these)
> [2006-03-31 13:00:01.720 ] 2636 LOG: could not fsync segment 0 of
> relation 1663/16385/1392439: Permission denied
> [2006-03-31 13:00:01.720 ] 2636 ERROR: storage sync failed on magnetic
> disk: Permission denied
Yoi. I think we
The middle tier transaction log indicates this record was inserted into
the county database at 2006-03-31 21:00:32.94. It would have hit the
central databases sometime thereafter (more or less immediately if all
was well).
The Panel table contains some running statistics which are updated
frequen
Tom Lane wrote:
> "Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> > AFAICS, int32 and int are exactly the same thing in PostgreSQL. For the
> > machine int is not 32 bits long, PostgreSQL won't even run.
>
> Ideally we should operate correctly if "int" is 64 bits. In practice
> I agree that making
"Peter Brant" <[EMAIL PROTECTED]> writes:
> One thing that seems strange to me is that the original crash on
> Thursday failed on Panel_pkey, but my "vacuum analyze verbose" on a copy
> of the crashed database failed on MaintCode /
> pg_statistic_relid_att_index.
I can't find anything particularly
Per the DBAs, there hadn't been any recent crashes before last Thursday.
A "vacuum analyze verbose" discovered the problem early Thursday
morning. After the PANIC, the database never came back up (the
heap_clean_redo: no block / full_page_writes = off problem).
One thing that seems strange to me
"Peter Brant" <[EMAIL PROTECTED]> writes:
> I can't find any duplicates?!?
Weirder and weirder. Maybe the table is OK but the index is corrupt?
Could it be another symptom of the same problem we're seeing in the
Panel_pkey index? I'm currently theorizing that that index might've
been corrupted
I can't find any duplicates?!?
The query
select starelid, staattnum, ctid, xmin, xmax, cmin, cmax
from pg_statistic p1
where (select count(*) from pg_statistic p2 where
p1.starelid = p2.starelid and p1.staattnum = p2.staattnum) > 1
doesn't turn up anything. Nor does dumping
select starelid,
"Peter Brant" <[EMAIL PROTECTED]> writes:
> Item 85 -- Length: 56 Offset: 2120 (0x0848) Flags: USED
> Block Id: 640 linp Index: 1 Size: 56
> Has Nulls: 0 Has Varwidths: 16384
> Item 86 -- Length: 56 Offset: 2176 (0x0880) Flags: USED
> Block Id: 635 linp Index: 1 Size: 56
>
"Peter Brant" <[EMAIL PROTECTED]> writes:
> bigbird=# vacuum analyze "MaintCode";
> ERROR: duplicate key violates unique constraint
> "pg_statistic_relid_att_index"
Hm, can you see any rows in pg_statistic with duplicate values of
(starelid, staattnum)? If so it'd be useful to look at their
ctid
It is repeatable. A reindex doesn't work.
Pete
bigbird=# vacuum analyze "MaintCode";
ERROR: duplicate key violates unique constraint
"pg_statistic_relid_att_index"
bigbird=# vacuum analyze verbose "MaintCode";
INFO: vacuuming "public.MaintCode"
INFO: index "MaintCode_pkey" now contains 19 r
11 matches
Mail list logo
