On Thu, Aug 5, 2010 at 7:28 PM, Alvaro Herrera
wrote:
>
> The scope is further reduced by the fact that this only seems to happen
> on Windows, and then only when the antivirus is messing around with the
> files.
So I suspect this could be triggered lots of ways. Imagine a ZFS
volume that runs ou
Heikki Linnakangas writes:
> On 05/08/10 21:28, Alvaro Herrera wrote:
>> Excerpts from Tom Lane's message of jue ago 05 14:01:15 -0400 2010:
>>> Maybe write-the-buffers-first is a sufficient longterm solution.
>>
>> Yeah, perhaps it is, though it's a pity that a single platform problem
>> is goin
On 05/08/10 21:28, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of jue ago 05 14:01:15 -0400 2010:
Maybe write-the-buffers-first is a sufficient longterm solution.
Yeah, perhaps it is, though it's a pity that a single platform problem
is going to slow down everyone else.
How about
Excerpts from Tom Lane's message of jue ago 05 14:01:15 -0400 2010:
> You're right, I misremembered. That code is just plain gone in 9.0:
> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/nbtree/nbtree.c.diff?r1=1.174;r2=1.175;f=h
>
> Still, we have a live issue with heap trunc
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of jue ago 05 13:19:41 -0400 2010:
>> In any case, the removal of VACUUM FULL didn't completely disable
>> shrinking of btree indexes did it? I don't recall having removed
>> that.
> I see no call to RelationTruncate in the btvacuumscan c
Excerpts from Tom Lane's message of jue ago 05 13:19:41 -0400 2010:
> In any case, the removal of VACUUM FULL didn't completely disable
> shrinking of btree indexes did it? I don't recall having removed
> that.
I see no call to RelationTruncate in the btvacuumscan code, but then it
was only call
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of jue ago 05 12:36:24 -0400 2010:
>> Gone? Looks like it's still there to me.
> I mean the btree code that does the truncation on vacuum full is
> truncated. There are other uses for truncation, but it doesn't look to
> that they are as
Excerpts from Tom Lane's message of jue ago 05 12:36:24 -0400 2010:
> Alvaro Herrera writes:
> > Excerpts from Tom Lane's message of jue ago 05 11:06:57 -0400 2010:
> >> 1. Write the dirty buffers before dropping them. Kind of ugly from a
> >> performance viewpoint, but simple and safe.
>
> > I
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of jue ago 05 11:06:57 -0400 2010:
>> 1. Write the dirty buffers before dropping them. Kind of ugly from a
>> performance viewpoint, but simple and safe.
> I think "simple" is good, considering that this code is gone in 9.0 and
> HEAD. I
Excerpts from Tom Lane's message of jue ago 05 11:06:57 -0400 2010:
> Seems like we need to think harder about recovering from a truncate
> failure. A few random ideas:
Ugh.
> 1. Write the dirty buffers before dropping them. Kind of ugly from a
> performance viewpoint, but simple and safe.
I
Hitesh Bhambhani writes:
>> From: Alvaro Herrera [mailto:alvhe...@commandprompt.com]
>> Sent: Wednesday, August 04, 2010 11:30 PM
>> There probably is. What kind of relation are the ones unable to truncate?
>> Please see in pg_class where relfilenode = '41274' in this
>> case:
>>
> [HiteshB] the
Hitesh Bhambhani wrote:
> Could you give an example of what an 'extraordinary circumstance'
> would be?
Normal vacuums will remove old tuples (versions of rows) which can
no longer be seen by any transaction, and make that space available
for re-use within the PostgreSQL files. It will not no
Greg, thanks for your answers.
My comments below...
> From: gsst...@gmail.com [mailto:gsst...@gmail.com] On Behalf Of Greg Stark
> Sent: Wednesday, August 04, 2010 9:35 PM
> Firstly, the current release of 8.2 is 8.2.17. There are a long list of bugs
> fixed in those intervening releases includin
Alvaro, thanks for your response.
My comments below...
> From: Alvaro Herrera [mailto:alvhe...@commandprompt.com]
> Sent: Wednesday, August 04, 2010 11:30 PM
> There probably is. What kind of relation are the ones unable to truncate?
> Please see in pg_class where relfilenode = '41274' in this
>
On Thu, Aug 5, 2010 at 12:55 PM, Hitesh Bhambhani
wrote:
> [HiteshB] I have noted your recommendation and will work with our Product
> Management to upgrade to the latest and greatest. Although we can't change
> the version that the customer has installed (8.2.9-1).
>
The latest and greatest is
Excerpts from Hitesh Bhambhani's message of mié ago 04 17:47:12 -0400 2010:
> Based on some logs in the Webapp I can see that there were some errors in
> truncating relations. Once those errors disappear the index corruption
> errors start. I'm not sure if there is a connection here.
There proba
On Wed, Aug 4, 2010 at 10:47 PM, Hitesh Bhambhani wrote:
>
> PostgreSQL version: 8.2.9-1
Firstly, the current release of 8.2 is 8.2.17. There are a long list
of bugs fixed in those intervening releases including one involving
vacuum truncating relations. I don't think it's the same problem but I
The following bug has been logged online:
Bug reference: 5599
Logged by: Hitesh Bhambhani
Email address: hite...@asg.com
PostgreSQL version: 8.2.9-1
Operating system: Microsoft Windows Server 2003, Enterprise Edition
Description:Vacuum fails due to index corruption is
18 matches
Mail list logo
