>> If a new unlogged relation is created after constructed the >> unloggedHash before sending file, we cannot exclude such relation. It >> would not be problem if the taking backup is not long because the new >> unlogged relation unlikely becomes so large. However, if takeing a >> backup takes a long time, we could include large main fork in the >> backup. > > This is a good point. It's per database directory which makes it a > little better, but maybe not by much. > > Three options here: > > 1) Leave it as is knowing that unlogged relations created during the > backup may be copied and document it that way. > > 2) Construct a list for SendDir() to work against so the gap between > creating that and creating the unlogged hash is as small as possible. > The downside here is that the list may be very large and take up a lot > of memory. > > 3) Check each file that looks like a relation in the loop to see if it > has an init fork. This might affect performance since an > opendir/readdir loop would be required for every relation. > > Personally, I'm in favor of #1, at least for the time being. I've > updated the docs as indicated in case you and Adam agree.
I agree with #1 and feel the updated docs are reasonable and sufficient to address this case for now. I have retested these patches against master at d6ab720360. All test succeed. Marking "Ready for Committer". -Adam
