Thread: postgresql 8.3rc1 on vista

postgresql 8.3rc1 on vista

From
Niederland
Date:
On my laptop which I use for development (Windows VISTA), I tried
Postgresql 8.3 RC1.  I ran into one problem... It seems that either
the service is not finding the postgresql.conf file or not paying
attention to the search_path within it.  This worked in all the
previous 8.2.x, 8.1.x I've used.

I defined a search path which contains some of the schemas...

search_path = 'public,dmsif,rawrr,rawadp,quartz'    # schema names

Using pgadmin (also the same result with my application).

Select * from qrtz_fired_triggers
returns:
ERROR:  relation "qrtz_fired_triggers" does not exist

and
select * from quartz.qrtz_fired_triggers
works as expected.

Just to verify the installation the service, is pointing to the
correct data directory.

Any suggestions?



Re: postgresql 8.3rc1 on vista

From
Niederland
Date:
Here's more information:  It appears that the postgresql.conf file is
not being used...

executing a show all; from psql
I see that the parameters are using the default values and not paying
attention to the settings in the postgresql.conf file.

The config_file has a value of c:/program files/PostgreSQL/8.3-rc1/
data/postgresql.conf
and the data_directory is c:/program files/PostgreSQL/8.3-rc1/data

I verified data is being placed under that directory and the database
is working as expected.
I also verified that changes in the hba_file (setting it to a trust
access) works.
hba_file has a value of c:/program files/PostgreSQL/8.3-rc1/data/
pg_hba.conf

Why aren't the changes in the postgresql.conf file reflected in the
show all; (of course after a restart via the service)?

Just a side note the executable path in the service shown below also
looks correct.
"C:\Program Files\PostgreSQL\8.3-rc1\bin\pg_ctl.exe" runservice -w -N
"pgsql-8.3-rc1" -D "C:\Program Files\PostgreSQL\8.3-rc1\data\"

Is the path to the postgresql.conf file handled differently then the
path to the pg_hba.conf file?

Thanks

Re: postgresql 8.3rc1 on vista

From
Niederland
Date:
This seems to be an installer bug for VISTA

If I run postgres via the command prompt with:
postgres -D ../data
then the postgres.conf file is loaded as confirmed with a show all in
psql

If I start postgres via the service which is installed with installer
the postgres.conf file values are not loaded.

But I confirmed that the service is reading the postgres.conf file.
Just to test I deleted the file, and the service would not start.

Any suggestions?

Thanks,
Roger



Re: postgresql 8.3rc1 on vista

From
Andrei Kovalevski
Date:
Hello,

The first thing which should be checked on Vista - correct file access
permissions. Did you create postgres.conf yourself?

Niederland wrote:
> This seems to be an installer bug for VISTA
>
> If I run postgres via the command prompt with:
> postgres -D ../data
> then the postgres.conf file is loaded as confirmed with a show all in
> psql
>
> If I start postgres via the service which is installed with installer
> the postgres.conf file values are not loaded.
>
> But I confirmed that the service is reading the postgres.conf file.
> Just to test I deleted the file, and the service would not start.
>
> Any suggestions?
>
> Thanks,
> Roger
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>


--
Andrei Kovalevski
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/


Re: postgresql 8.3rc1 on vista

From
Niederland
Date:
Yes I checked the file permissions... In fact I logged in as the user
specified in the service and started postgres via the command line
with
postgres -D ../data
and the postgres.conf parameters were loaded as confirmed with a "show
all" in psql

And still running postgresql from the service does not load the
parameters from the postgres.conf file.

So it does not seem like a permissions issue.