On 2021-Mar-11, Peter Geoghegan wrote: > On Thu, Mar 11, 2021 at 8:13 AM Alvaro Herrera <[email protected]> > wrote: > > I disagree; that GUC was a feature in its own right, and it seems likely > > that people have set it in the hopes that it'd help them, even if it > > didn't actually achieve that. > > Michael was talking about the reloption, not the GUC. Surely the GUC > is not the problem here - there is plenty of precedent for removing > GUCs that were around for many releases, without considering > compatibility.
Sorry, yes, I meant the reloption. I agree we don't care about the GUC. > > > You could have made the same arguments against removing > > > recheck_on_update in commit 1c53c4de. > > > > recheck_on_update was born on 11.0 and killed in time for 11.1, so its > > opportunity to become set was narrower. > > New reloptions are added infrequently. And they're practically never > removed. So recheck_on_update seems to be the closest thing to a > precedent. Given the short life of recheck_on_update I don't think we should consider it a precedent. > I now accept that the dump/reload hazards when upgrading to 14 are not > acceptable. ISTM that adding back the reloption on master/Postgres 14 > (without doing anything with it) is the only way to fix everything. Yeah, I agree. It would be slightly better to ignore it on input (ie. make ALTER TABLE SET a no-op for that case), but I don't think we have code to do that. > Any thoughts on that plan? I can do that in the next few hours if > there are no objections. Sounds good to me. -- Álvaro Herrera 39°49'30"S 73°17'W
