>> Uh, I guess we could write some code that iterates over all tables and >> finds the tables that should have TOAST tables, but don't (because >> binary-upgrade backend mode suppressed their creation), and adds them. >> >> However, that would be a lot of code and might be risky to backpatch. >> The error is so rare I am not sure it is worth it. I tried to create >> the failure case and it was very difficult, requiring me to create the >> problem table first, then some dummy stuff to get the offsets right so >> the oid would collide. >> >> Based on the rareness of the bug, I am not sure it is worth it, but if >> it is, it would be something only for 9.4 (maybe) and 9.5, not something >> to backpatch. > > Another idea would be to renumber empty toast tables that conflict > during new toast table creation, when in binary upgrade mode. Since the > files are always empty in binary upgrade mode, you could just create a > new toast table, repoint the old table to use (because it didn't ask for > a specific toast table oid because it didn't need one), and then use > that one for the table that actually requested the oid. However, if one > is a heap (zero size), and one is an index (8k size), it wouldn't work > and you would have to recreate the file system file too. > > That seems a lot more localized than the other approaches.
To me, that sounds vastly more complicated and error-prone than forcing the TOAST tables to be added in a second pass as Andres suggested. But I just work here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
