Hi, Thanks for the feedback.
> Which approach do you think we should use? I think we have decent > patches for both approaches at this point, so perhaps we should see if > we can get some additional feedback from the community on which one we > should pursue further. In my opinion both the approaches have benefits over current implementation. I think in keep-trying-the-next-file approach we have handled all rare and specific scenarios which requires us to force a directory scan to archive the desired files. In addition to this with the recent change to force a directory scan at checkpoint we can avoid an infinite wait for a file which is still being missed out despite handling the special scenarios. It is also more efficient in extreme scenarios as discussed in this thread. However, multiple-files-per-readdir approach is cleaner with resilience of current implementation. I agree that we should decide on which approach to pursue further based on additional feedback from the community. > The problem I see with this is that pgarch_archiveXlog() might end up > failing. If it does, we won't retry archiving the file until we do a > directory scan. I think we could try to avoid forcing a directory > scan outside of these failure cases and archiver startup, but I'm not > sure it's really worth it. When pgarch_readyXlog() returns false, it > most likely means that there are no .ready files present, so I'm not > sure we are gaining a whole lot by avoiding a directory scan in that > case. I guess it might help a bit if there are a ton of .done files, > though. Yes, I think it will be useful when we have a bunch of .done files and the frequency of .ready files is such that the archiver goes to wait state before the next WAL file is ready for archival. > I agree, but it should probably be something like DEBUG3 instead of > LOG. I will update it in the next patch. Thanks, Dipesh
