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(at)postgreSQL(dot)org
> > [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of Tom Lane
> > Sent: Thursday, September 02, 1999 1:36 PM
> > To: pgsql-hackers(at)postgreSQL(dot)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(at)tpf(dot)co(dot)jp
>
> ************
>

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