Re: DDL Damage Assessment

* Claudio Freire (klaussfreire(at)gmail(dot)com) wrote:
> On Thu, Oct 2, 2014 at 6:19 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> >> And that needs locks, especially if you modify the underlying filesystem layout.
> >
> > And we wouldn't be doing that, certainly. It's a dry-run.
>
> ...
>
> > (...) We might also be able to simply get away with
> > short-circuiting them and not actually writing anything (and the same
> > for reading data..). What would probably be useful is to review actual
> > migration scripts and see if this would really work. I know they'd work
> > for at least a subset of the migration scripts that I've dealt with
> > before, and also not all of them.
>
> I believe, for it to be reasonably intrusive, you'd have to abort at
> the first need to actually read/write data.
>
> Most of my migration scripts, especially the ones that would benefit
> from this, require some of that, but that's just my personal common
> practice, not a general case.

I realize we're moving into real pie-in-the-sky ideas here, but I wonder
if we could have a way to either create a new 'delta' fork which
maintains the pages which have been changed.. Or perhaps actually have
a new relfileno with a reference back to the original for any empty
pages..

> > The point is to not write anything which is visible to other
> > transactions, which means we'd have to put DML into some different
> > 'mode' which doesn't actually write where other processes might be
> > looking. I'm not saying it's trivial to do, but I don't think it's
> > impossible either. (...)
>
> No, I don't think it's impossible either. Just very, very
> time-consuming. Both in developing the patch and in its eventual
> maintenance.

I agree that we don't want a completely independent code path for this
or it won't be as useful- and that's a concern for the EXPLAIN idea too.

> TBH, a separate read-only transaction like explain alter would also be
> quite difficult to keep in sync with actual alter logic, unless it's
> handled by the same code (unlikely in that form).

Right.

Thanks,

Stephen