On 2018-06-19 12:17:59 -0400, Andrew Dunstan wrote:
>
>
> On 06/19/2018 12:05 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2018-06-19 11:51:16 -0400, Andrew Dunstan wrote:
> > > My initial thought was that as a fallback we should disable pg_upgrade on
> > > databases containing such values, and document the limitation in the docs
> > > and the release notes. The workaround would be to force a table rewrite
> > > which would clear them if necessary.
> > I personally would say that that's not acceptable. People will start
> > using fast defaults - and you can't even do anything against it! - and
> > suddenly pg_upgrade won't work. But they will only notice that years
> > later, after collecting terrabytes of data in such tables.
>
>
> Umm, barring the case that Tom mentioned by then it would just work.
Huh?
> It's not the case that if they put in fast default values today they
> will never be able to upgrade.
How? I mean upgrading and loosing your default values certainly ain't
ok? And we can't expect users to rewrite their tables, that's why we
added fast default support and why pg_upgrade is used.
> I'd at least like to see what a solution might look like before ruling it
> out. I suspect I can come up with something in a day or so. The work
> wouldn't be wasted.
I think it'd be unacceptable to release v11 without support, but I also
think it's quite possible to just add the necessary logic for v11 if we
put some effort into it. ISTM we've resolved worse issues during beta
than this.
Greetings,
Andres Freund