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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
