RE: [HACKERS] md.c is feeling much better now, thank you

I think that, based on this, the changes should be back'd out of v6.5.2
until further testing and analysis can be done.  If we have to, we can do
a v6.5.3 at a later date, if you want to get this in then...

On Thu, 2 Sep 1999, Hiroshi Inoue wrote:

> 
> > -----Original Message-----
> > From: owner-pgsql-hackers@postgreSQL.org
> > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
> > Sent: Thursday, September 02, 1999 1:36 PM
> > To: pgsql-hackers@postgreSQL.org
> > Subject: [HACKERS] md.c is feeling much better now, thank you
> > 
> > 
> > Hiroshi spotted the fundamental problem we were having:
> > RelationFlushRelation would happily flush a relation-cache
> > entry that still had an open file entry at the md.c and fd.c
> > levels.  This resulted in a permanent leak of md and vfd
> > file descriptors, which was most easily observable as a leakage
> > of kernel file descriptors (though fd.c would eventually
> > recycle same).  smgrclose() in RelationFlushRelation fixes it.
> >
> 
> Thanks.
> 
> But I'm unhappy with your change for mdtruncate().
> It's still dangerous to unlink unwanted segments in mdtruncte().
> 
> StartTransaction() and CommandCounterIncrement() trigger
> relation cache invalidation. Unfortunately those are insufficient 
> to prevent backends from inserting into invalid relations.
> 
> For exmaple
>  
> If a backend is blocked by vacuum,it would insert into the target 
> relation without relation cache invalidation after vacuum.
> 
> It seems that other triggers are necessary around LockRelation().  
> 
> Regards.
> 
> Hiroshi Inoue
> Inoue@tpf.co.jp
> 
> ************
> 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org