On Tue, Aug 17, 2021 at 12:42 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Actually though ... I've not read the patch, but what does it do about > the fact that the postgres and template0 DBs do not have stable OIDs? > I cannot imagine any way to force those to match across PG versions > that would not be an unsustainable crock.
Well, it's interesting that you mention that, because there's a comment in the patch that probably has to do with this: + /* + * Make sure that pg_upgrade does not change database OID. Don't care + * about "postgres" database, backend will assign it fixed OID anyway. + * ("template1" has fixed OID too but the value 1 should not collide with + * any other OID so backend pays no attention to it.) + */ I wasn't able to properly understand that comment, and to be honest I'm not sure I precisely understand your concern either. I don't quite see why the template0 database matters. I think that database isn't going to be dumped, or restored, so as far as pg_upgrade is concerned it might as well not exist in either cluster, and I don't see why pg_upgrade can't therefore just ignore it completely. But template1 and postgres are another matter. If I understand correctly, those databases are going to be created in the new cluster by initdb, but then pg_upgrade is going to populate them with data - including relation files - from the old cluster. And, yeah, I don't see how we could make those database OIDs match, which is not great. To be honest, what I'd be inclined to do about that is just nail down those OIDs for future releases. In fact, I'd probably go so far as to hardcode that in such a way that even if you drop those databases and recreate them, they get recreated with the same hard-coded OID. Now that doesn't do anything to create stability when people upgrade from an old release to a current one, but I don't really see that as an enormous problem. The only hard requirement for this feature is if we use the database OID for some kind of encryption or integrity checking or checksum type feature. Then, you want to avoid having the database OID change when you upgrade, so that the encryption or integrity check or checksum in question does not have to be recomputed for every page as part of pg_upgrade. But, that only matters if you're going between two releases that support that feature, which will not be the case if you're upgrading from some old release. Apart from that kind of feature, it still seems like a nice-to-have to keep database OIDs the same, but if those cases end up as exceptions, oh well. Does that seem reasonable, or am I missing something big? -- Robert Haas EDB: http://www.enterprisedb.com