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.
I think the root of the problem with this feature is that it doesn't go through shared_buffers, so in my opinion, it would be better if we can make it all go through shared_buffers. It seems like you're advocating a middle ground where half of the operation goes through shared_buffers and the other half doesn't, but that sounds like getting rid of half of the hack when we could have gotten rid of all of it. I think things that don't go through shared_buffers are bad, and we should be making an effort to get rid of them where we can reasonably do so. I believe I've both introduced and fixed my share of bugs that were caused by such cases, and I think the behavior of the whole system would be a lot easier to reason about if we had fewer of those, or none. 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. -- Robert Haas EDB: http://www.enterprisedb.com
