Additional informations:

• my Postgresql Version is 10.6
• I tried installation without Docker on a plane Ubuntu 18.04 - the same result.

• My database admin and I analysed the behaviour of the installation process. There is really an error occurring in the database:

  2019-04-17 14:25:47.812 CEST,"limesurveyplayground_admin","limesurveyplayground",20287,"10.153.99.8:42138",5cb71b4b.4f3f,3,"SELECT",2019-04-17 14:25:47 EST,116/74592,0,ERROR,42P01,"relation ""lime_users"" does not exist",,,,,,"SELECT * FROM ""lime_users""",15,,""

  BUT: This error happens BEFORE I press the button "populate database". After pressing the button the table will be created. An later on the next page I get this error.

It seems to me that the "SELECT * FROM lime_users" maybe is executed to test if an old installation exist. But later in the installation process, after table creation, someone has forgotten to execute the select statement again. And so the old result caused the failure - just a guess.

I am sorry but I cannot reproduce the problem. I can install on Postgres without problems.
The error indicated that the user table was not created. So can you check if the user table really exists at that point where the error shows up?

As I mentioned above, we find an error message (in the db logs) when accessing the users table BEFORE we push the "populate database button" ! Maybe or maybe not that there is an relation of this db error to the later php error.

To repoduce the problem again I erased the schema with:

drop schema limesurveyplayground cascade;
create schema limesurveyplayground;

Then started the installation process again - and failed again.

I made a pg_dump of the database created by your installation process. As you can see there is a table lime_users created!

Kind Regards,
Roman Fischer

If you do install again and again with same DB but different prefix : remind to clean up tmp/runtime directiry too. (maybe not related, just an idea)

As you can see on this little screenshot, the tmp/runtime directory is quite empty - what should I remove?

Try to upload again :-)

emptyRuntime.PNG (28,763 bytes)

BTW: I don't you different table prefixes, I removed the whole database schema and recreated it.

(maybe not related, just an idea)

My database administrator created a new PostgresSQL cluster and a new database. We got the same error. I attached the whole DB log (inclusive DB creation) and the apache access log, Attentions: It seems that the clocks of both servers are a little bit out of sync, so that may confuse when comparing the logs. Are there any other logs created while installation process (I did not find any)?

I found the reason for this error: Our database administration don't like to use the "public" schema. So when creating a database they create inside a new schema (named the same as database itself) and revoking all access rights to the "public" schema.

For testing purposes I created a new database without a new schema, so that the database has only the "public" schema.

USING THIS DATABASE HAVING ONLY A PUBLIC SCHEMA - THE INSTALLATION PROCESS WORKED CORRECTLY!!!

Conclusion: The Installation procedure don't ask me for a database schema name. Surprisingly it finds my schema and creates the tables in it. But at a later screen it seems that the procecure looks in the public schema again (and don't find the users table):

Suggestions:

• prevent Installation when public schema is not available
• work with the automatically selected schema correctly
• user Input of the wanted schema name, and work correctly with ist :-) - my prevered solution

Regards, Roman Fischer

Short additional Information: Maybe the tables are created because our database admin sets the search path of the database to our created schema.

Hey Roman,

thank you for the feedback. Problem is/was that 'schema' does not exist in other database systems so it is never something we even considered to be a problem as the installation procedure needs to be compatible for all database systems (MySQL, Postgres and MSSQL)