From: | Jeff Frost <jeff(at)frostconsultingllc(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: delete and select with IN clause issues |
Date: | 2006-11-07 23:08:43 |
Message-ID: | Pine.LNX.4.64.0611071507220.23695@discord.home.frostconsultingllc.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Fri, 3 Nov 2006, Tom Lane wrote:
> Well, I can't find anything wrong :-(. There are some differences in
> the list of contained keys, but they're all up near the end of the
> range, which is consistent with the assumption that the table is live
> and had some changes between your two dumps of the index. In
> particular, there's no difference in the entries for the troublesome
> key value:
>
> 38635629 24080 25
> 38635629 24080 26
> 38635629 24080 27
>
> So I dunno what to make of it. If it happens again, we need to look
> more closely.
Well, it's been working wonderfully since the REINDEX, so I don't know what to
say. Any idea if having a too small max_fsm_pages could hose an index,
because I know that happened not too long before we started seeing this
problem. The fsm settings were increased prior to the problem occurring, but
it's possible the index was already damaged?
--
Jeff Frost, Owner <jeff(at)frostconsultingllc(dot)com>
Frost Consulting, LLC http://www.frostconsultingllc.com/
Phone: 650-780-7908 FAX: 650-649-1954
From | Date | Subject | |
---|---|---|---|
Next Message | gurkan | 2006-11-07 23:49:06 | Re: converting Informix outer to Postgres |
Previous Message | Scott Marlowe | 2006-11-07 18:03:08 | Re: Nested select |