On Wed, Sep 8, 2021 at 9:54 PM Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Sep 3, 2021 at 5:54 PM Andres Freund <and...@anarazel.de> wrote: > > > I think we already have such a code in multiple places where we bypass > the > > > shared buffers for copying the relation > > > e.g. index_copy_data(), heapam_relation_copy_data(). > > > > That's not at all comparable. We hold an exclusive lock on the relation > at > > that point, and we don't have a separate implementation of reading > tuples from > > the table or something like that. > > I don't think there's a way to do this that is perfectly clean, so the > discussion here is really about finding the least unpleasant > alternative. I *really* like the idea of using pg_class to figure out > what relations to copy. As far as I'm concerned, pg_class is the > canonical list of what's in the database, and to the extent that the > filesystem happens to agree, that's good luck. From that perspective, > using the filesystem to figure out what to copy is by definition a > hack. > I agree with you, even though I think that scanning pg_class for identifying the relfilenode looks like a more sensible thing to do than directly scanning the file system, we need to consider one point that, now also in current system (in create database) we are scanning the directory for copying the file so instead of copying them directly we need to logically identify the relfilenode and then copy it block by block, so maybe this approach will not make anyone unhappy because it is not any worse than the current system. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
