Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> Tom Lane írta:
>> What that sounds like to me is a corrupt index (infinite loop of
>> right-links, perhaps). Have you tried REINDEXing the table?
> How can such an infinite loop sneak into an index?
> Hardware is from Sun, not a grocery store PC, s
On Thu, 2008-06-12 at 11:56 -0400, Andrew Sullivan wrote:
> On Thu, Jun 12, 2008 at 05:31:37PM +0200, Zoltan Boszormenyi wrote:
>
> > Hardware is from Sun, not a grocery store PC, so I don't suppose it to
> > be faulty.
>
> FWIW, I had a pair of E4500s in one job that I would _happily_ have
> t
On Thu, Jun 12, 2008 at 05:31:37PM +0200, Zoltan Boszormenyi wrote:
> Hardware is from Sun, not a grocery store PC, so I don't suppose it to
> be faulty.
FWIW, I had a pair of E4500s in one job that I would _happily_ have
traded for any beige box you care to mention. Heck, at the end I
mighta tr
Tom Lane írta:
> Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
>
>> The realtime trace I captured from the hung INSERT shows that it
>> enters two functions repeatedly: _bt_relandgetbuf() and _bt_compare().
>> The pattern in which these functions entered match either _bt_moveright() or
>> _bt_i
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> The realtime trace I captured from the hung INSERT shows that it
> enters two functions repeatedly: _bt_relandgetbuf() and _bt_compare().
> The pattern in which these functions entered match either _bt_moveright() or
> _bt_insertonpg().
What that so
Zoltan Boszormenyi wrote:
> This is so embarrassing that the file and its only index used up only 3.3MB,
> at the time of my testing no one else used the database, shared_buffers is
> large enough to hold both the index and the table data totally:
I would be embarrased if this was on a recent rel
Gregory Stark írta:
> "Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
>
>
>> Also, VACUUM FULL also takes too much time, on an otherwise idle database, I
>> worked on a copy of their live database. During VACUUM, _bt_getbuf() was
>> also called repeatedly with the block number jumping up and do
"Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
> Also, VACUUM FULL also takes too much time, on an otherwise idle database, I
> worked on a copy of their live database. During VACUUM, _bt_getbuf() was
> also called repeatedly with the block number jumping up and down.
VACUUM or VACUUM FULL? VA
Hi,
we have a customer with PostgreSQL 8.0.3 with a quite interesting problem.
They have around 24 identical databases and all but one is working nicely.
The one that doesn't work nicely show this problem: INSERT "hangs"
on an apparently empty table where "select count(*)" returns 0 quite
quickly.
