Now when doing this on Windows this is *bound* to fail because the "Program
Files" are usually not writeable for non-admin users. The directory is
created during installation by the user running the installation (which is
usually an admin user). The PG service runs under a regular user account and
thus fails to write to the data directory. The sympton is that the service
simply fails, but you can't see any errors because PG can't write to the log
file as well.
It's not bound to fail because part of the installation process is to
grant the require permissions on whatever directory is chosen for the
data. In the case of the one-click installers, this is tested
extensively before every release on a range of clean and dirty virtual
machines including XP, Vista, 2K3 and 2K8, and on the Mac on Leopard,
Tiger and Leopard Server.
OK, that's good news, but then those failures need to have a different source.
But interesting enough the problems were all caused by wrong permissions (just
look at the thread I pointed to in dbforums).
If you can supply an installation log that would help diagnose the
problem.
I'll ask them, but I doubt I can get hold of them.
Where would the log be stored?
If it's hard to find a good default for the datadir I suggest to leave it
completely empty and actively ask the user to specify a directory and give a
big hint that this directory must be writeable for the postgres user
account.
In the majority of installations the postgres account is created by
the installer so it's not feasible to grant the permissions in
advance.
Yes, but the data dir is created *after* the acount is created, correct?
But still: I think it is a much better strategy to *not* put the data dir into
the program directory.
Additionally when creating the data dir from within the installer, it should
set the permissions of that directory to make sure the postgres user can
really write to it.
As I said above, they all do. I can point you at the code if you're interested.
I believe you :)
The installer(s) should also ask some question for the default configuration
so that pg_hba.conf and postgres.conf can be pre-configured to e.g. accept
connections from other computers. A simple checkbox during the installation
wizard would be enough for this, which would then adjust listen_address in
postgresql.conf and the host entries in pg_hba.conf
Well, we intentionally don't do that in the one-click installers for
precisely the reason you give above!
You mean for security reasons?
Hmm. But isn't that essential to a DBMS to be able to be contacted from the
outside?
Thanks for the feedback. I finally see some people understanding the advantages
Postgres has over other choices, but these situations surely weren't ideal to
promote Postgres which is a bit sad..
Cheers
Thomas
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
