Re: Postgres 7.3 from source --with-tcl : Errors again...

Jason,

[this is just a digression from the main subject, but not off topic]

Anyway, if plTcl is harder to manage to compile, I think a more usefull tcl approach would be to have a cygwin autotools enabled pgtcl binding library. In my opinion a lot of users come to pl/Tcl as a quick way to have graphical interfaces to postgresql, not necessary because of their better skills in tcl than e.g. pl/pgSQL.

As I said, I manually built pl/Tcl, but I must confess I didn't test whether it worked or not. But pgTcl with its pgAccess as a main purpose does.

SLao

__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

SLao,

On Wed, Jan 22, 2003 at 01:59:29AM -0500, S. L. wrote:
> Anyway, if plTcl is harder to manage to compile, I think a more
> usefull tcl approach would be to have a cygwin autotools enabled pgtcl
> binding library. In my opinion a lot of users come to pl/Tcl as a
> quick way to have graphical interfaces to postgresql, not necessary
> because of their better skills in tcl than e.g. pl/pgSQL.

I will leave it to others to address the above.

Anyway, I started to debug the PL/Tcl problem. These are my
observations:

1. pltcl.dll is successfully loaded by postgres
2. pltcl.dll is successfully loading cygtcl83.dll (which is not
surprising since the Windows loader does this)
3. pltcl.dll is failing in pltcl_init_all() (which is very early in the
initialization process)
4. Tcl_CreateInterp() succeeds (so at least one Tcl function seems to
work)
5. Tcl_CreateSlave() fails (unfortunately, I could not determine why
with a limited amount of effort)

I will leave it to those who have the interest to continue
debugging this problem.

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

On Thu, Jan 23, 2003 at 07:51:21AM -0500, Jason Tishler wrote:
> Anyway, I started to debug the PL/Tcl problem. These are my
> observations:
>
> 1. pltcl.dll is successfully loaded by postgres
> 2. pltcl.dll is successfully loading cygtcl83.dll (which is not
> surprising since the Windows loader does this)
> 3. pltcl.dll is failing in pltcl_init_all() (which is very early in the
> initialization process)
> 4. Tcl_CreateInterp() succeeds (so at least one Tcl function seems to
> work)
> 5. Tcl_CreateSlave() fails (unfortunately, I could not determine why
> with a limited amount of effort)
>
> I will leave it to those who have the interest to continue
> debugging this problem.

I believe that I have figured out why Tcl_CreateSlave() failed above.
Since Cygwin Tcl/Tk is a hybrid Cygwin/Win32 it needs TCL_LIBRARY (and
possibly TK_LIBRARY) set with Win32 paths:

export TCL_LIBRARY=$(cygpath -w /usr/share/tcl8.4) TK_LIBRARY=$(cygpath -w /usr/share/tk8.4)

This seems to get PL/Tcl much further. However, it now fails during the
first insert with the following:

LOG: server process (pid 2960) exited with exit code 128
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing shared memory and semaphores
IpcMemoryCreate: shmget(key=5432001, size=638976, 03600) failed: Not enough core

This error usually means that PostgreSQL's request for a shared
memory segment exceeded available memory or swap space.
To reduce the request size (currently 638976 bytes), reduce
PostgreSQL's shared_buffers parameter (currently 16) and/or
its max_connections parameter (currently 4).

The PostgreSQL Administrator's Guide contains more information about
shared memory configuration.

Unfortunately, the standard fix of increasing

HKCU\Software\Cygnus Solutions\Cygwin\heap_chunk_in_mb

doesn't seem to help. :,(

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6