[BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running

[Mark Llewellyn]

The following bug has been logged online:

Bug reference:  5650
Logged by:  Mark Llewellyn
Email address:  mark_llewel...@adp.com
PostgreSQL version: 9.0 RC1
Operating system:   Windows XP
Description:Postgres service showing as stopped when in fact it is
running
Details: 

The postgresql-9.0 service is showing as *not running* in pgAdmin 3 1.12 RC1
and as *stopped* in the Windows services list, although the database is
actually running and I can connect to it and create databases, tables etc.
It also shows multiple postgresql tasks in Windows task manager.
However, because Windows XP is not aware that the postgresql-9.0 service is
running it is not possible to stop the service.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Before I call it a bug - some comments and questions

[Chris Browne]

mamf...@gmail.com (Michael Felt) writes:
> I have just run compiled postgres on AIX (AIX 5.3, pgsql version 8.4.4) and
> have a few surprises regarding the make process.
>
> 1. Very nice - it found gmake as /usr/local/bin/make and called GNUmakefile
> 2. The make completes and it starts a test.
> -- As I build, generally, as root - this failed because initdb does not want 
> to
> run as root
> -- su to another user after changing ownership of the files, fails because not
> enough space (maybe check for space)
> -- enlarge filesystem, run make again, tests all succeed, and then make fails
> trying to install docs (not root!)
> --- why is the initial make installing/copying anything outside of the project
> directory (in this case it was /usr/local/pgsql if I recall correctly).
> --- My non-root user has no right to write there, so the "build" failed again.
>
> 3. A question: what is the best way to get the make process to install in a
> alturnate directory. Some projects use an environment variable.

See the output of

./configure --help

Commonly, I find it sufficient to specify the alternate location via:

   ./configure --prefix=/path/where/pg/stuff/should/live

That implies bin/, include/, share/, lib/ and other such target
directories.  If you have very specific needs, configure options should
hopefully accommodate them.

> 4. Minor point: why is /usr/local/include not in the -I list by default? I had
> to add CFLAGS=-I/usr/local/include for configure to complete.

That's not a standard place to put #include files across all of the
operating systems on which Postgres runs, so it wouldn't be proper to
have it as a default.

Not all systems have /usr/local/include, and on some systems, adding
this would point the compile to *wrong* code.  Consider the case where
an engineer at a company like Red Hat (Tom? ;-)) is building official
packages for a Linux distribution.

- On the machine where the build is being done, there might well exist a
  /usr/local/include directory.

- But it shouldn't be used, because the *right* #includes to use for the
  build are in /usr/include.

- They might have /usr/local/include there specifically as a test that
  programs should *NOT* be referencing it without specific instruction
  to do so!  I could imagine stowing #includes there that are designed
  to make stuff break.  Probably not a good thing on an Official Build
  Server, but an excellent torture test for a QA server :-).

-- 
(format nil "~...@~s" "cbbrowne" "gmail.com")
The statistics on  sanity are that one out of  every four Americans is
suffering from some  form of mental illness. Think  of your three best
friends. If they're okay, then it's you. -- Rita Mae Brown

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Before I call it a bug - some comments and questions

[Tom Lane]

Michael Felt  writes:
> -- As I build, generally, as root - this failed because initdb does not want
> to run as root

Many people regard that as bad practice ...

> --- why is the initial make installing/copying anything outside of the
> project directory (in this case it was /usr/local/pgsql if I recall
> correctly).

Because that's the default installation prefix.

> 3. A question: what is the best way to get the make process to install in a
> alturnate directory. Some projects use an environment variable.

configure --prefix=/some/path

> 4. Minor point: why is /usr/local/include not in the -I list by default?

That would be something to ask your compiler vendor.  It's no business
of postgres' to assume that some non-default -I switches are
appropriate.  I believe that gcc is very often configured to include
/usr/local in its default -I path, but that's up to local custom.

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] Before I call it a bug - some comments and questions

[Michael Felt]

I have just run compiled postgres on AIX (AIX 5.3, pgsql version 8.4.4) and
have a few surprises regarding the make process.

1. Very nice - it found gmake as /usr/local/bin/make and called GNUmakefile
2. The make completes and it starts a test.
-- As I build, generally, as root - this failed because initdb does not want
to run as root
-- su to another user after changing ownership of the files, fails because
not enough space (maybe check for space)
-- enlarge filesystem, run make again, tests all succeed, and then make
fails trying to install docs (not root!)
--- why is the initial make installing/copying anything outside of the
project directory (in this case it was /usr/local/pgsql if I recall
correctly).
--- My non-root user has no right to write there, so the "build" failed
again.

3. A question: what is the best way to get the make process to install in a
alturnate directory. Some projects use an environment variable.

4. Minor point: why is /usr/local/include not in the -I list by default? I
had to add CFLAGS=-I/usr/local/include for configure to complete.

Regards,
Michael

Re: [BUGS] BUG #5641: Can not create any python language

[Ashesh Vashi]

Hi Ron,

I am able to reproduce the issue on my side..
Thanks for the report.

I found that - plpython.dll is not exporting any plpython_call_handler
function, but plpython3_call_handler.

For the work around, you can follow this link:
1) Go to PostgreSQL lib directory
i.e. C:\Program Files\PostgreSQL\9.0\lib
2) Copy plpython.dll as plpython3.dll in the same directory.

Now, try to create the plpython3u language in PostgreSQL.
i.e. CREATE LANGUAGE plpython3u;

This is just a temporary solution and I wish - this solves the problem for
you.
We will come up with a better solution soon.

--
*Thanks & Regards,*
*
*
*Ashesh Vashi*
*EnterpriseDB INDIA:* Enterprise Postgres Company

On Thu, Sep 9, 2010 at 3:25 PM, Ashesh Vashi
wrote:

> Hi,
>
> Can you share the postgresql log file, when you tried to create the python
> language on PG 9.0?
>
> --
> Thanks & Regards,
>
> Ashesh Vashi
>  EnterpriseDB INDIA
>
>
> On Fri, Sep 3, 2010 at 3:03 AM, Ron Park  wrote:
>
>>
>> The following bug has been logged online:
>>
>> Bug reference:  5641
>> Logged by:  Ron Park
>> Email address:  rpar...@gmail.com
>> PostgreSQL version: 9.0
>> Operating system:   Windows 7 professional 64 bit
>> Description:Can not create any python language
>> Details:
>>
>> when trying to create plpythonu
>>
>> ERROR:  could not find function "plpython_call_handler" in file
>> "C:/Program
>> Files/PostgreSQL/9.0/lib/plpython.dll"
>>
>>
>> when trying to create plpython2u or plpython3u I get
>> ERROR:  could not access file "$libdir/plpython2": No such file or
>> directory
>>
>> ERROR:  could not access file "$libdir/plpython3": No such file or
>> directory
>>
>>
>> I have python2.6, python3.1, python3.2 all installed (64 bit).  All are in
>> the path variable.
>>
>> used 9.0 MSI from enterprise to install postgresql 9.0
>>
>> I have been running and using the 8.xx ones on windows 32 bit and ubuntu
>> for
>> 6 years and have been able to get python to behave well on both systems.
>> But I am at a loss here.. Looks like there is a bug in the plpython.dll
>> missing the call handler???  Not sure
>>
>> --
>> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-bugs
>>
>
>

Re: [BUGS] BUG #5641: Can not create any python language

[Ashesh Vashi]

Hi,

Can you share the postgresql log file, when you tried to create the python
language on PG 9.0?

--
Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA


On Fri, Sep 3, 2010 at 3:03 AM, Ron Park  wrote:

>
> The following bug has been logged online:
>
> Bug reference:  5641
> Logged by:  Ron Park
> Email address:  rpar...@gmail.com
> PostgreSQL version: 9.0
> Operating system:   Windows 7 professional 64 bit
> Description:Can not create any python language
> Details:
>
> when trying to create plpythonu
>
> ERROR:  could not find function "plpython_call_handler" in file "C:/Program
> Files/PostgreSQL/9.0/lib/plpython.dll"
>
>
> when trying to create plpython2u or plpython3u I get
> ERROR:  could not access file "$libdir/plpython2": No such file or
> directory
>
> ERROR:  could not access file "$libdir/plpython3": No such file or
> directory
>
>
> I have python2.6, python3.1, python3.2 all installed (64 bit).  All are in
> the path variable.
>
> used 9.0 MSI from enterprise to install postgresql 9.0
>
> I have been running and using the 8.xx ones on windows 32 bit and ubuntu
> for
> 6 years and have been able to get python to behave well on both systems.
> But I am at a loss here.. Looks like there is a bug in the plpython.dll
> missing the call handler???  Not sure
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>