On Thu, Mar 11, 2021 at 12:39 PM Alvaro Herrera <[email protected]> wrote: > Given the short life of recheck_on_update I don't think we should > consider it a precedent.
Now we have a useful precedent. Apparently there is no way to truly remove a storage parameter. That seems a little annoying, but not worth spending too much time on. > > 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. That would be better, certainly. > > Any thoughts on that plan? I can do that in the next few hours if > > there are no objections. > > Sounds good to me. I just pushed a fix that does that. In addition, I reverted the changes to REL_11_STABLE and REL_12_STABLE, meaning that crake will go back to testing Thanks -- Peter Geoghegan
