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

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgreSQL(dot)org>
Subject: RE: [HACKERS] md.c is feeling much better now, thank you
Date: 1999-09-02 10:32:02
Message-ID: 000b01bef52e$6526e0a0$2801007e@cadzone.tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Leon 1999-09-02 12:25:11 Re: [HACKERS] Postgres' lexer
Previous Message Oleg Bartunov 1999-09-02 10:30:49 Commercial question