Hi, On 2021-06-17 13:53:38 -0400, Robert Haas wrote: > On Thu, Jun 17, 2021 at 5:20 AM Heikki Linnakangas <hlinn...@iki.fi> wrote: > > You only need relpersistence if you want to use the buffer cache, right? > > I think that's a good argument for not using it.
Do we really need pg_class to figure this out? Can't we just check if the relation has an init fork? > I can also think of at least one significant advantage of driving this > off the remote database's pg_class rather than the filesystem > contents. It's a known defect of PostgreSQL that if you create a table > and then crash, you leave behind a dead file that never gets removed. > If you now copy the database that contains that orphaned file, you > would ideally prefer not to copy that file, but if you do a copy based > on the filesystem contents, then you will. If you drive the copy off > of pg_class, you won't. I'm very unconvinced this is the place to tackle the issue of orphan relfilenodes. It'd be one thing if it were doable by existing code, e.g. because we supported cross-database relation accesses fully, but we don't. Adding a hacky special case implementation for cross-database relation accesses that violates all kinds of assumptions (like holding a lock on a relation when accessing it / pinning pages, processing relcache invals, ...) doesn't seem like a good plan. I don't think this is an academic concern: You need to read from shared buffers to read the "remote" pg_class, otherwise you'll potentially miss changes. But it's not correct to read in pages or to pin pages without holding a lock, and there's code that relies on that (see e.g. InvalidateBuffer()). Greetings, Andres Freund
