From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DDL Damage Assessment |
Date: | 2014-10-02 21:08:16 |
Message-ID: | CAGTBQpbesM4ervZG1K70P6u6o5y=yKvecLggf6vQ9pGMXBiSBg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 2, 2014 at 6:03 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Claudio Freire (klaussfreire(at)gmail(dot)com) wrote:
>> On Thu, Oct 2, 2014 at 4:40 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> > The downside of the 'explain' approach is that the script then has to be
>> > modified to put 'explain' in front of everything and then you have to go
>> > through each statement and consider it. Having a 'dry-run' transaction
>> > type which then produces a report at the end feels like it'd be both
>> > easier to assess the overall implications, and less error-prone as you
>> > don't have to prefex every statement with 'explain'. It might even be
>> > possible to have the local "view" of post-alter statements be available
>> > inside of this 'dry-run' option- that is, if you add a column in the
>> > transaction then the column exists to the following commands, so it
>> > doesn't just error out. Having 'explain <whatever>' wouldn't give you
>> > that and so you really wouldn't be able to have whole scripts run by
>> > just pre-pending each command with 'explain'.
>>
>> That sounds extremely complex. You'd have to implement the fake
>> columns, foreign keys, indexes, etc on most execution nodes, the
>> planner, and even system views.
>
> Eh? We have MVCC catalog access.
And that needs locks, especially if you modify the underlying filesystem layout.
>> IMO, dry-run per se, is a BEGIN; stuff; ROLLBACK. But that still needs
>> locks. I don't think you can simulate the side effects without locks,
>
> Why? If you know the transaction is going to roll back and you only add
> entries to the catalog which aren't visible to any other transactions
> than your own, and you make sure that nothing you do actually writes
> data out which is visible to other transactions..
But that's not the scope. If you want a dry-run of table-rewriting
DDL, or DDL interspersed with DML like:
alter table blargh add foo integer;
update blargh set foo = coalesce(bar, baz);
You really cannot hope not to have to write data. The above is also
the case with defaulted columns btw.
>> so getting the local view of changes will be extremely difficult
>> unless you limit the scope considerably.
>
> I agree that there may be complexities, but I'm not sure this is really
> the issue..
In essence, if you want MVCC catalog access without AEL, you're in for
a rough ride. I'm not as experienced with pg's core as you, so you
tell me, but I imagine it will be the case.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2014-10-02 21:08:30 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
Previous Message | Claudio Freire | 2014-10-02 21:04:18 | Re: DDL Damage Assessment |