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

On Thu, 5 Feb 2004, Tom Lane wrote:

> * Because we don't smgrclose after a write, it is possible to have
> "dangling" smgr entries that aren't useful any more, as well as open
> file descriptors underneath them. This isn't too big a deal on Unix
> but it will be fatal for the Windows port, since it would prevent a
> DROP TABLE if some other backend happens to have touched the table.
> What I propose to do about this is:
> 1. In the bgwriter, at each checkpoint do "smgrcloseall" to close
> all open files.
> 2. In regular backends, receipt of a relcache flush message will
> result in smgrclose(), even if there is not a relcache entry
> for the given relation ID. A global cache flush event (sinval
> buffer overflow) causes smgrcloseall.
> This ensures that open descriptors for a dead relation will not persist
> past the next checkpoint. We had already agreed, I think, that the
> best solution for Windows' problem with deleting open files is to retry
> pending deletes at checkpoint. This smgr rewrite will not contribute
> to actually making that happen, but it won't make things worse either.

'k, only comment is on this one ... would it not be a bit more efficient
to add a flag to the "SMgrRelation *" structure that acts as a timer? if
-1, then relation is deleted, is >0, make it epoch of the time that
Relation was last accessed? then your 'smgrcloseall', instead of closing
all files (even active/undeleted ones), would only close those that are
either idle for x minutes (maybe a postgresql.conf tunable there?) or
those that have been DROP'd? Assuming, that is, that your end goal is to
reduce the overall # of open/closes of files ... this way, instead of
closing 20 just to reopen 19 of them, you only close that one that needs
it ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664