On Tue, Apr 16, 2019 at 06:40:44PM -0400, Robert Haas wrote: > Yeah, I really hope we don't end up with dueling patches. I want to > come up with an approach that can be widely-endorsed and then have > everybody rowing in the same direction. On the other hand, I do think > that we may support multiple options in certain places which may have > the kinds of trade-offs that Bruce mentions. For instance, > identifying changed blocks by scanning the whole cluster and checking > the LSN of each block has an advantage in that it requires no prior > setup or extra configuration. Like a sequential scan, it always > works, and that is an advantage. Of course, for many people, the > competing advantage of a WAL-scanning approach that can save a lot of > I/O will appear compelling, but maybe not for everyone. I think > there's room for two or three approaches there -- not in the sense of > competing patches, but in the sense of giving users a choice based on > their needs.
Well, by having a separate modblock file for each WAL file, you can keep both WAL and modblock files and use the modblock list to pull pages from each WAL file, or from the heap/index files, and it can be done in parallel. Having WAL and modblock files in the same directory makes retention simpler. In fact, you can do an incremental backup just using the modblock files and the heap/index files, so you don't even need the WAL. Also, instead of storing the file name and block number in the modblock file, using the database oid, relfilenode, and block number (3 int32 values) should be sufficient. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
