On Mon, Mar 9, 2020 at 8:55 AM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > This may be a good time to think through about how to implement a > version history for an extension that enables users to go from pg12's > current 1.7 pageinspect to a new fixed version in pg12, say 1.7.1, and > in HEAD provide an upgrade path from both 1.7 and 1.7.1 to master's 1.8. > Then you can pg_upgrade from pg12 to pg13 having either 1.7 or 1.7.1, > and you will be able to get to 1.8 nonetheless. > > Does that make sense?
Sort of. The main problem with that idea is that it requires the user to notice that the problem is in the extension definition itself, which is a pretty rare edge case -- how many people will follow through with that? You could deliberately break it so they'd have to notice it, which is what I did here, but I don't think that users would appreciate seeing that in a point release. Especially for something like bt_metap(), which kind of worked before. There are also implementation problems. You might need rather a lot of upgrade paths. While the most significant problem by far here is with the oldest_xact column, this bug was in the earliest version of the pageinspect extension. Even 1.0 uses int4 where it should use something that works as BlockNumber (I used int8 for this here). That's just messy. > The current problem might not be serious enough to warrant actually > writing the code that would be needed, but I propose to at least think > about it. I briefly considered doing something like targeting the backbranches by making oldest_xact display XIDs greater than 2^31-1 as negative values, or as NULL, with a NOTICE message. I quickly concluded that the cure would be worse than the disease. -- Peter Geoghegan
