Обсуждение: More info
Any idea why 6.5.3 would have created tens of thousands of files like these in the /data/base/db_geocrawler/ directory? There may have even been a million of these files there - so many that rm -f idx_arch_date_list_year_mo.* didn't work. Tim idx_arch_date_list_year_mo.10548 idx_arch_date_list_year_mo.1981 idx_arch_date_list_year_mo.6827 pg_class_relname_index.2653 idx_arch_date_list_year_mo.10549 idx_arch_date_list_year_mo.1982 idx_arch_date_list_year_mo.6828 pg_class_relname_index.2654 idx_arch_date_list_year_mo.1055 idx_arch_date_list_year_mo.1983 idx_arch_date_list_year_mo.6829 pg_class_relname_index.2655 idx_arch_date_list_year_mo.10550 idx_arch_date_list_year_mo.1984 idx_arch_date_list_year_mo.683 pg_class_relname_index.2656 idx_arch_date_list_year_mo.10551 idx_arch_date_list_year_mo.1985 idx_arch_date_list_year_mo.6830 pg_class_relname_index.2657 idx_arch_date_list_year_mo.10552 idx_arch_date_list_year_mo.1986 idx_arch_date_list_year_mo.6831 pg_class_relname_index.2658 idx_arch_date_list_year_mo.10553 idx_arch_date_list_year_mo.1987 idx_arch_date_list_year_mo.6832 pg_class_relname_index.2659 idx_arch_date_list_year_mo.10554 idx_arch_date_list_year_mo.1988 idx_arch_date_list_year_mo.6833 pg_class_relname_index.266 idx_arch_date_list_year_mo.10555 idx_arch_date_list_year_mo.1989 idx_arch_date_list_year_mo.6834 pg_class_relname_index.2660 idx_arch_date_list_year_mo.10556 idx_arch_date_list_year_mo.199 idx_arch_date_list_year_mo.6835 pg_class_relname_index.2661 idx_arch_date_list_year_mo.10557 idx_arch_date_list_year_mo.1990 idx_arch_date_list_year_mo.6836 pg_class_relname_index.2662 idx_arch_date_list_year_mo.10558 idx_arch_date_list_year_mo.1991 idx_arch_date_list_year_mo.6837 pg_class_relname_index.2663 idx_arch_date_list_year_mo.10559 idx_arch_date_list_year_mo.1992 idx_arch_date_list_year_mo.6838 pg_class_relname_index.2664 idx_arch_date_list_year_mo.1056 idx_arch_date_list_year_mo.1993 idx_arch_date_list_year_mo.6839 pg_class_relname_index.2665 idx_arch_date_list_year_mo.10560 idx_arch_date_list_year_mo.1994 idx_arch_date_list_year_mo.684 pg_class_relname_index.2666 idx_arch_date_list_year_mo.10561 idx_arch_date_list_year_mo.1995 -- Founder - PHPBuilder.com / Geocrawler.com Lead Developer - SourceForge VA Linux Systems 408-542-5723
Tim Perdue <tperdue@valinux.com> writes:
> Any idea why 6.5.3 would have created tens of thousands of files like
> these in the /data/base/db_geocrawler/ directory?
Funny you should mention that, because I was just in process of testing
a fix when your mail came in. The low-level routine that accesses a
particular segment of a multi-segment relation develops a serious case
of Sorcerer's Apprentice syndrome if higher levels hand it a silly block
number. If you tell it to access, say, block# 2 billion, it will
merrily start creating empty segment files till it gets to the segment
number that corresponds to that block number.
The routine does need to be able to create *one* new segment, in case it
is asked to access the block just past the current EOF (when EOF is at a
segment boundary) ... but not more than one. As of current sources, it
knows not to do more.
This bug has been known for a while. It doesn't directly answer your
problem though, since the real issue is "what generated the silly block
number, and why"?
I can't quite resist the temptation to suggest that you should be
running 7.0.2 ...
regards, tom lane
Tom Lane wrote: > I can't quite resist the temptation to suggest that you should be > running 7.0.2 ... I'll tell you what I *really* want... How about 7.1.2 (I'm afraid of 7.1.0) Tim -- Founder - PHPBuilder.com / Geocrawler.com Lead Developer - SourceForge VA Linux Systems 408-542-5723
Tim Perdue <tperdue@valinux.com> writes:
> Tom Lane wrote:
>> I can't quite resist the temptation to suggest that you should be
>> running 7.0.2 ...
> I'll tell you what I *really* want... How about 7.1.2 (I'm afraid of
> 7.1.0)
And when that's out, you'll be waiting for 7.2.2?
I can understand reluctance to install whatever.0 as a production
server on its first day of release. But we have enough field experience
now with 7.0.* to say confidently that it is more stable than 6.5.*,
and we know for a fact that we have fixed hundreds of bugs in it
compared to 6.5.*. Frankly, if I had to bet today, I'd bet on 7.1.*
being less stable than 7.0.*, at least till we shake out all the
implications of TOAST, WAL, etc.
If you're being bitten by 6.5.* bugs then an update seems in order.
regards, tom lane
> I can understand reluctance to install whatever.0 as a production > server on its first day of release. But we have enough field experience > now with 7.0.* to say confidently that it is more stable than 6.5.*, > and we know for a fact that we have fixed hundreds of bugs in it > compared to 6.5.*. Frankly, if I had to bet today, I'd bet on 7.1.* > being less stable than 7.0.*, at least till we shake out all the > implications of TOAST, WAL, etc. Is WAL planned for 7.1? What is the story with WAL? I'm a bit concerned that the current storage manager is going to be thrown in the bit bucket without any thought for its benefits. There's some stuff I want to do with it like resurrecting time travel, some database replication stuff which can make use of the non-destructive storage method etc. There's a whole lot of interesting stuff that can be done with the current storage manager.
WAL is 7.1. It doesn't affect the storage manager very much. A new storage manager is scheduled for 7.2. > > > I can understand reluctance to install whatever.0 as a production > > server on its first day of release. But we have enough field experience > > now with 7.0.* to say confidently that it is more stable than 6.5.*, > > and we know for a fact that we have fixed hundreds of bugs in it > > compared to 6.5.*. Frankly, if I had to bet today, I'd bet on 7.1.* > > being less stable than 7.0.*, at least till we shake out all the > > implications of TOAST, WAL, etc. > > Is WAL planned for 7.1? What is the story with WAL? I'm a bit concerned > that the current storage manager is going to be thrown in the bit bucket > without any thought for its benefits. There's some stuff I want to do > with it like resurrecting time travel, some database replication stuff > which can make use of the non-destructive storage method etc. There's a > whole lot of interesting stuff that can be done with the current storage > manager. > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote: > > WAL is 7.1. It doesn't affect the storage manager very much. A new > storage manager is scheduled for 7.2. Is it going to hurt my ability to resurrect time travel using the original methodology?