Bruce Momjian wrote: > Kevin Brown wrote: > > Bruce Momjian wrote: > > > The idea of using this on Unix is tempting, but Tatsuo is using a > > > threaded backend, so it is a little easier to do. However, it would > > > probably be pretty easy to write a file of modified file names that the > > > checkpoint could read and open/fsync/close. > > > > Even that's not strictly necessary -- we *do* have shared memory we > > can use for this, and even when hundreds of tables have been written > > the list will only end up being a few tens of kilobytes in size (plus > > whatever overhead is required to track and manipulate the entries). > > > > But even then, we don't actually have to track the *names* of the > > files that have changed, just their RelFileNodes, since there's a > > mapping function from the RelFileNode to the filename. > > But we have to allow an unlimited number of files. Perhaps we could > just fall back to sync if the shared memory overflows, and shared memory > is finite.
True. Hmm...perhaps there's another way to do this? Let me explain: When we do a checkpoint what we're really doing is writing any committed transactions in the transaction log to the associated data files, right? Or, so the theory goes. PG may do something quite different than that. I'm not terribly familiar with the source and so it may be no surprise that I'm having difficulty finding any code that converts transactions stored in the transaction log into changes to the data files... Anyway, if a checkpoint really does take transactions and commit them to the data files, then the transactions themselves contain all the information we need. So there would be no need to maintain a separate list: the list has already been stored on disk for us. All we'd have to do is build a list at checkpoint time and fsync/fdatasync each file in the list at the very end. The list wouldn't need to be shared because the only process that would care is the one doing the checkpointing. Or so the theory goes. Since I'm having so much trouble finding code that actually does any of what I describe, I'd have no trouble believing that how PG works is very different than I envision... -- Kevin Brown [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
