RE: [HACKERS] md.c is feeling much better now, thank you
От | Hiroshi Inoue |
---|---|
Тема | RE: [HACKERS] md.c is feeling much better now, thank you |
Дата | |
Msg-id | 000b01bef52e$6526e0a0$2801007e@cadzone.tpf.co.jp обсуждение исходный текст |
Ответ на | md.c is feeling much better now, thank you (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
RE: [HACKERS] md.c is feeling much better now, thank you
Re: [HACKERS] md.c is feeling much better now, thank you |
Список | pgsql-hackers |
> -----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
В списке pgsql-hackers по дате отправления: