Re: Postmaster holding unlinked files for pg_largeobject table - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Postmaster holding unlinked files for pg_largeobject table
Date
Msg-id 1307395045-sup-3303@alvh.no-ip.org
Whole thread Raw
In response to Re: Postmaster holding unlinked files for pg_largeobject table  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Postmaster holding unlinked files for pg_largeobject table
List pgsql-hackers
Excerpts from Tom Lane's message of lun jun 06 12:49:46 -0400 2011:
> Robert Haas <robertmhaas@gmail.com> writes:

> > Instead of closing them immediately, how about flagging the FD and
> > closing all the flagged FDs at the end of each query, or something
> > like that?
> 
> Hmm, there's already a mechanism for closing "temp" FDs at the end of a
> query ... maybe blind writes could use temp-like FDs?

I don't think it can be made to work exactly like that.  If I understand
correctly, the code involved here is the FlushBuffer() call that happens
during BufferAlloc(), and what we have at that point is a SMgrRelation;
we're several levels removed from actually being able to set the
FD_XACT_TEMPORARY flag which is what I think you're thinking of.

What I think would make some sense is to keep a list of SMgrRelations
that we opened during FlushBuffer that are foreign to the current
database, in the current ResourceOwner.  That way, when the resowner is
destroyed, we would be able to smgrclose() them.  This would only be
done when called by a backend, not bgwriter.

(I'm not really sure about requiring the buffer to belong to a relation
in another database, given the report that this is also a problem with
dropped tables.  However, it certainly makes no sense to try to remember
*all* buffers.)

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Darren Duncan
Date:
Subject: Re: Range Types and extensions
Next
From: Simon Riggs
Date:
Subject: Re: WALInsertLock tuning