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