Re: smgrsettransient mechanism is full of bugs

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@postgreSQL.org
Date: 2012-10-15T19:38:50Z
Lists: pgsql-hackers

Attachments

I wrote:
> I got a bit suspicious of the transient-file mechanism introduced in
> commit fba105b1099f4f5fa7283bb17cba6fed2baa8d0c after noticing that
> ...
> I believe that we probably ought to revert this mechanism entirely, and
> build a new implementation based on these concepts:
> * An SMgrRelation is transient if and only if it doesn't have an
> "owning" relcache entry.  Keep a list of all such SmgrRelations, and
> close them all at transaction end.  (Obviously, an SMgrRelation gets
> removed from the list if it acquires an owner mid-transaction.)
> * There's no such concept as FD_XACT_TRANSIENT at the fd.c level.
> Rather, we close and delete the VFD entry when told to by SmgrRelation
> closure.

Attached is a draft patch for that, presented in two parts: the first
part just reverts commit fba105b1099f4f5fa7283bb17cba6fed2baa8d0c,
and the second part installs the new mechanism.  I'm reasonably pleased
with the way this turned out; I think it's cleaner as well as more
reliable than the previous patch.

The list-management code could possibly be replaced with slist once that
patch goes in, but since this needs to be back-patched, I didn't
consider that for the moment.

Comments?

			regards, tom lane

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Use "transient" files for blind writes, take 2