{"push_id":1100860912,"size":1,"distinct_size":1,"ref":"refs/heads/REL9_4_STABLE","head":"e1aecebc041db969abe7cacb351577938f11a2af","before":"1180868d11343f4ec01bf5d4964e360fceaab5ff","commits":[{"sha":"e1aecebc041db969abe7cacb351577938f11a2af","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix pg_upgrade to not fail when new-cluster TOAST rules differ from old.\n\nThis patch essentially reverts commit 4c6780fd17aa43ed, in favor of a much\nsimpler solution for the case where the new cluster would choose to create\na TOAST table but the old cluster doesn't have one: just don't create a\nTOAST table.\n\nThe existing code failed in at least two different ways if the situation\narose: (1) ALTER TABLE RESET didn't grab an exclusive lock, so that the\nlock sanity check in create_toast_table failed; (2) pg_upgrade did not\nprovide a pg_type OID for the new toast table, so that the crosscheck in\nTypeCreate failed.  While both these problems were introduced by later\npatches, they show that the hack being used to cause TOAST table creation\nis overwhelmingly fragile (and untested).  I also note that before the\nTypeCreate crosscheck was added, the code would have resulted in assigning\nan indeterminate pg_type OID to the toast table, possibly causing a later\nOID conflict in that catalog; so that it didn't really work even when\ncommitted.\n\nIf we simply don't create a TOAST table, there will only be a problem if\nthe code tries to store a tuple that's wider than a page, and field\ncompression isn't sufficient to get it under a page.  Given that the TOAST\ncreation threshold is intended to be about a quarter of a page, it's very\nhard to believe that cross-version differences in the do-we-need-a-toast-\ntable heuristic could result in an observable problem.  So let's just\nfollow the old version's conclusion about whether a TOAST table is needed.\n\n(If we ever do change needs_toast_table() so much that this conclusion\ndoesn't apply, we can devise a solution at that time, and hopefully do\nit in a less klugy way than 4c6780fd17aa43ed did.)\n\nBack-patch to 9.3, like the previous patch.\n\nDiscussion: <8110.1462291671@sss.pgh.pa.us>","distinct":true,"url":"https://api.github.com/repos/postgres/postgres/commits/e1aecebc041db969abe7cacb351577938f11a2af"}]}