Обсуждение: vacuum crash on 6.5.3

Поиск
Список
Период
Сортировка

vacuum crash on 6.5.3

От
Tatsuo Ishii
Дата:
Althoug this happens on old 6.5.3, I would like to know if this has
been already fixed...

Here is the scenario:

1) before vacuum, table A has 8850 tuples.

2) vacuum on table A makes postgres crashed.

3) it crashes at line 1758:
Assert(num_moved == checked_moved);
I examined variables using gdb. num_moved == 8849, check_moved ==8813, num_tuples == 18.

4) if PostgreSQL is not compiled with assertion, vacuum does not  crash. However, after vacuum, the number of tuples
descreasesfrom  8850 to 8814!! (I am not sure which number is correct, though)
 

I think this is an important problem since a data loss might
happen. Any idea?
--
Tatsuo Ishii


Re: vacuum crash on 6.5.3

От
Tatsuo Ishii
Дата:
> Althoug this happens on old 6.5.3, I would like to know if this has
> been already fixed...
> 
> Here is the scenario:
> 
> 1) before vacuum, table A has 8850 tuples.
> 
> 2) vacuum on table A makes postgres crashed.
> 
> 3) it crashes at line 1758:
> 
>     Assert(num_moved == checked_moved);
> 
>     I examined variables using gdb. num_moved == 8849, check_moved ==
>     8813, num_tuples == 18.
> 
> 4) if PostgreSQL is not compiled with assertion, vacuum does not
>    crash. However, after vacuum, the number of tuples descreases from
>    8850 to 8814!! (I am not sure which number is correct, though)
> 
> I think this is an important problem since a data loss might
> happen. Any idea?

It turns out that this was caused by vacuum's bug.  Thanks to Hiroshi,
he has identified the problem. I have checked other version of
PostgreSQL, and found that at we have had the bug at least since
6.3.2, and it has been fixed in 7.0. Included are patches for 6.5.3 and
a test sript to reproduce the bug. Both of them are made by Hiroshi.
--
Tatsuo Ishii

RE: vacuum crash on 6.5.3

От
"Hiroshi Inoue"
Дата:
Just a supplement.
Essentially this isn't a crash bug.
This had been a disastrous bug that causes data loss silently.
(This is known as 'HEAP_MOVED_IN was not expected' bug
but the result could be more serious than I've recognized.) 

Please apply the patch if you still have pre-7.0 pg db-s and
you don't love data loss.

Regards.
Hiroshi Inoue

> -----Original Message-----
> From: Tatsuo Ishii
> 
> > Althoug this happens on old 6.5.3, I would like to know if this has
> > been already fixed...
> > 
> > Here is the scenario:
> > 
> > 1) before vacuum, table A has 8850 tuples.
> > 
> > 2) vacuum on table A makes postgres crashed.
> > 
> > 3) it crashes at line 1758:
> > 
> >     Assert(num_moved == checked_moved);
> > 
> >     I examined variables using gdb. num_moved == 8849, check_moved ==
> >     8813, num_tuples == 18.
> > 
> > 4) if PostgreSQL is not compiled with assertion, vacuum does not
> >    crash. However, after vacuum, the number of tuples descreases from
> >    8850 to 8814!! (I am not sure which number is correct, though)
> > 
> > I think this is an important problem since a data loss might
> > happen. Any idea?
> 
> It turns out that this was caused by vacuum's bug.  Thanks to Hiroshi,
> he has identified the problem. I have checked other version of
> PostgreSQL, and found that at we have had the bug at least since
> 6.3.2, and it has been fixed in 7.0. Included are patches for 6.5.3 and
> a test sript to reproduce the bug. Both of them are made by Hiroshi.
> --
> Tatsuo Ishii
>