On Fri, Feb 18, 2022 at 4:30 AM Robert Haas <robertmh...@gmail.com> wrote: > > > > This thread is long. Could you summarize what lead you to consider other > > approaches (e.g. looking in the filesystem for relfilenodes) as not > > feasible / > > too ugly / ...? > > I don't think it's infeasible to look at the filesystem for files and > just copy whatever files we find. It's a plausible alternate design. I > just don't like it as well. I think that relying on the filesystem > contents to tell us what's going on is kind of hacky. The only > technical issue I see there is that the WAL logging might require more > kludgery, since that mechanism is kind of intertwined with > shared_buffers. You'd have to get the right block references into the > WAL record, and you have to make sure that checkpoints don't move the > redo pointer at an inopportune moment.
Actually based on the previous discussion, I also tried to write the POC with the file system scanning approach to identify the relation to be copied seet patch 0007 in this thread [1]. And later we identified one issue [2], i.e. while scanning directly the disk file we will only know the relfilenode but we can not identify the relation oid that means we can not lock the relation. Now, I am not saying that there is no way to work around that issue but that was also one of the reasons for not pursuing that approach. [1] https://www.postgresql.org/message-id/CAFiTN-v1KYsVAhq_fOWFa27LZiw9uK4n4cz5XmQJxJpsVcfq1w%40mail.gmail.com [2] https://www.postgresql.org/message-id/CAFiTN-v%3DU58by_BeiZruNhykxk1q9XUxF%2BqLzD2LZAsEn2EBkg%40mail.gmail.com -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
