opened
l-wang
username_0
The alter database set tablesapce command should alter the tablespace on
QD and all the QEs. This patch adds dispatching of the alter database
set tablespace command to QEs. In Greenplum, the transaction should be
atomic across all the segments and master, hence need to use two phase
commit for this operation. Due to usage of 2PC, the implementation needs
to differ compared upstream, can't locally commit the transactions.
Catalog changes are committed and later using pending deletes, old
tablespace directory is removed only on commit.

Other alternative considered was using separate dispatch for deleting
the directory instead of using pending delete after commiting alter
database set tablespace transaction. But that seemed unnecessary
overhead compared to pending deletes approach.

Fixes #5643 Github issue.

Note: `dropdb()` currently is not MPP safe for similar reason, it uses 2PC but it deletes the database directory on each segment before commit. So if a segment fails, the database will remain in the catalog but on-disk files for some of the segments may be deleted. This makes the cluster inconsistent. We plan to fix `dropdb()` using the same logic proposed in this PR via pending deletes by moving the non-catalog related activities post commit. Hence, would really love to seek feedback first for its usage for alter database set tablespace.

Co-authored-by: Ashwin Agrawal <aagrawal@pivotal.io>
Co-authored-by: David Kimura <dkimura@pivotal.io>

## Here are some reminders before you submit the pull request
- [x] Add tests for the change
- [ ] Document changes
- [ ] Communicate in the mailing list if needed
- [x] Pass `make installcheck`
Make alter database set tablespace MPP ready
issue
created
Eulerizeit
username_1
comment
created
hlinnaka
username_2
On 15/02/2019 17:34, Robert Eckhardt wrote:
> On Fri, Feb 15, 2019 at 8:50 AM Heikki Linnakangas

Kind of. You couldn't move a database to a different tablespace after 
creating it. So you'd have to get it right, when you CREATE DATABASE. 
You could still move individual tables with ALTER TABLE SET TABLESPACE, 
though, just not the whole database.

- Heikki
comment
created
ashwinstar
username_3
Thanks a lot Heikki for the review. Given the storage tiers evolving these
days seems good functionality to ship if we can. Plus, irrespective we will
have to use this logic for drop database, and we see nothing wrong with it.
I feel we should provide the functionality given we didn't even beta yet,
yes its unfortunate we didn't get to this earlier ideally during merge
itself when we got the new command. But that's the cost we have to pay
delaying dealing with fixme's.
comment