Re: It's past time to redo the smgr API

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> On Thu, Feb 05, 2004 at 02:05:46PM -0500, Tom Lane wrote:
>> * smgrclose closes the md.c-level file and drops the hashtable entry.
>> Hashtable entries remain valid unless explicitly closed (thus, multiple
>> smgropens for the same file are legal).

> So, will there be a refcount on each cache entry?

No, I deliberately intended not. There is at most one persistent
reference to an smgr hashtable entry; that's the one in the relcache
entry for the relation. The only caller of smgrclose will be
relcache.c, and it'll do it only when clearing the relcache reference
(or, in the sinval case, upon determining that there is no relcache
entry for the relation). Adding a reference count would just complicate
matters --- for instance, we'd have to be able to reset them after an
error, which would be rather hard from smgr's point of view since it
really shouldn't be looking into the relcache to see if there's a
reference there.

>> I'm also thinking of merging smgr.c's existing
>> list-of-rels-to-be-deleted into this data structure.

> Please don't. In the nested transaction environment, each subxact has
> to keep track of which files should be deleted. That's why I was trying
> to set the list inside a transaction status stack.

Hm. Okay, I'll leave that separate for now, although I think we do want
to merge the structures eventually.

> Another way to do it would be keeping the list of files to delete along
> with the deleting Xid, but that would also require keeping a list of
> which xacts aborted and which ones didn't.

Really? When a subtransaction finishes, you either delete its files
immediately (ie, if it aborted, you can drop files it created) or you
reassign them as the responsibility of the parent (since any effects of
the subtransaction really depend on whether the parent commits, you
can't actually do its deletes yet). I don't see the need to remember
subtransaction state further than that. So ISTM all you need is one
field added to the existing list entries to remember which
subtransaction is currently "on the hook" for a given file-deletion
request.

regards, tom lane