Description of problem: If engine-setup is requested (which is the default) to automatically provision databases, and the databases exist and non-empty, it silently creates others with a different name (adding _TIMESTAMP). We handle this only during a rather late stage, after asking all the questions and starting the actual setup. Thus we can't (or do not want to) ask the user about this. This is because normally on a clean system postgres is not initialized yet at the customization stage. If we did create a base_TIMESTAMP database, we emit this in the end as a note to the user. Not sure why we do that. I never saw a case where this happened and was expected or wanted, and I did see several cases where this was not wanted but also not noticed (or noticed much later). IMO we should just abort in such a case. Users that want multiple databases on the same system and have them created by engine-setup, will have to supply an answer file with the requested names (named base_TIMESTAMP or any other name). Version-Release number of selected component (if applicable): 3.3 How reproducible: Always Steps to Reproduce: 1. Create a database 'engine' and some table in it 2. engine-setup, choose to automatically create a database Actual results: engine-setup creates a database engine_TIMESTAMP (e.g. engine_20150903112339) Expected results: engine-setup aborts, saying database 'engine' exists. Additional info:
1. this should be opened upstream not downstream, we have only one product, this behaviour is not downstream specific. 2. we minimize questions - the name of database should not be important if we provision. 3. database name can always changed later if actually required. 4. the above was the reason for this behavior.
(In reply to Alon Bar-Lev from comment #2) > 1. this should be opened upstream not downstream, we have only one product, > this behaviour is not downstream specific. > 2. we minimize questions - the name of database should not be important if > we provision. If we default to 'engine' and 'engine' exists and non-empty, imo we should not continue silently with a different name. IMO (and not only mine), in almost all such cases, this was a result of a bug and/or user error, almost never a conscious decision/will. > 3. database name can always changed later if actually required. > 4. the above was the reason for this behavior. Was this discussed anywhere? Is this documented anywhere? Do we have a bug/RFE asking this?
Do what you think best, I gave reasoning of current implementation.
(In reply to Alon Bar-Lev from comment #4) > Do what you think best, Very well. > I gave reasoning of current implementation. Thanks for that!
*** Bug 1072878 has been marked as a duplicate of this bug. ***
This is by design and the summary contains the new db name. If the user chose automatic and confirmed the summary, we should not block this.