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

Sun, 09 Jul 2000 20:52:47 -0700
Tim Perdue <tperdue@valinux.com>
More info
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

Mon, 10 Jul 2000 00:39:09 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: More info 
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

Mon, 10 Jul 2000 06:05:16 -0700
Tim Perdue <tperdue@valinux.com>
Re: More info
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

Mon, 10 Jul 2000 10:26:30 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: More info 

> 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.

Tue, 11 Jul 2000 10:38:39 +1000
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
postgres 7.2 features.
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, Pennsylvania 19026

Mon, 10 Jul 2000 20:58:44 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: postgres 7.2 features.
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?

Tue, 11 Jul 2000 11:29:01 +1000
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Re: postgres 7.2 features.