Re: Postmaster holding unlinked files for pg_largeobject table
Alvaro Herrera <alvherre@commandprompt.com>
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Kevin Grittner <kevin.grittner@wicourts.gov>, alexk <alexk@commandprompt.com>, Alexander Shulgin <ash@commandprompt.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-06-06T21:59:31Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Reset reindex-in-progress state before reverifying an exclusion constraint.
- dccfb72892ac 9.1.0 cited
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