Обсуждение: pgacess: cant find libpgctl (no faq !)
I compiled postgres 7.2.3 (--with-tcl) and newest pgacess (0.98.8.b2). While I got the libpgctl-libraries in the expected place and exported the PGLIB-variable I still get the error: Error: can not find libpgtcl.so shared library. # ls -l $PGLIB/libpgt* -rw-r--r-- 1 root root 31554 Oct 22 15:01 /opt/local/pgsql/lib/libpgtcl.a lrwxrwxrwx 1 root root 15 Oct 22 15:01 /opt/local/pgsql/lib/libpgtcl.so -> libpgtcl.so.2.2 lrwxrwxrwx 1 root root 15 Oct 22 15:01 /opt/local/pgsql/lib/libpgtcl.so.2 -> libpgtcl.so.2.2 -rwxr-xr-x 1 root root 36151 Oct 22 15:01 /opt/local/pgsql/lib/libpgtcl.so.2.2 # ls -l $PGLIB/libpq* -rw-r--r-- 1 root root 87764 Oct 22 15:01 /opt/local/pgsql/lib/libpq.a lrwxrwxrwx 1 root root 12 Oct 22 15:01 /opt/local/pgsql/lib/libpq.so -> libpq.so.2.2 lrwxrwxrwx 1 root root 12 Oct 22 15:01 /opt/local/pgsql/lib/libpq.so.2 -> libpq.so.2.2 -rwxr-xr-x 1 root root 70037 Oct 17 2001 /opt/local/pgsql/lib/libpq.so.2.1 -rwxr-xr-x 1 root root 79911 Oct 22 15:01 /opt/local/pgsql/lib/libpq.so.2.2 I also added the pglib-path to my ld.so.conf and I also copied the above libraries to my "normal" lib-path (/usr/local/lib) I also played around with trailing slashes and that stuff. My tcl-version is a recent one (8.3) and I couldnt find any older non-beta-pgaccess versions. Somewhere they say only 7.2.1 and 7.2.2 is supported but I'm sure they just didnt know about 7.2.3 when writing it on the wiki-web at www.pgaccess.org ;) thnx, peter ps: system is linux -- mag. peter pilsl IT-Consulting tel: +43-699-1-3574035 fax: +43-699-4-3574035 pilsl@goldfisch.at
On Tue, 2002-10-22 at 06:51, pilsl@goldfisch.at wrote:
> I compiled postgres 7.2.3 (--with-tcl) and newest pgacess (0.98.8.b2).
>
> While I got the libpgctl-libraries in the expected place and exported the
> PGLIB-variable I still get the error:
>
> Error: can not find libpgtcl.so shared library.
>
> # ls -l $PGLIB/libpgt*
> -rw-r--r-- 1 root root 31554 Oct 22 15:01 /opt/local/pgsql/lib/libpgtcl.a
> lrwxrwxrwx 1 root root 15 Oct 22 15:01 /opt/local/pgsql/lib/libpgtcl.so -> libpgtcl.so.2.2
> lrwxrwxrwx 1 root root 15 Oct 22 15:01 /opt/local/pgsql/lib/libpgtcl.so.2 -> libpgtcl.so.2.2
> -rwxr-xr-x 1 root root 36151 Oct 22 15:01 /opt/local/pgsql/lib/libpgtcl.so.2.2
> # ls -l $PGLIB/libpq*
> -rw-r--r-- 1 root root 87764 Oct 22 15:01 /opt/local/pgsql/lib/libpq.a
> lrwxrwxrwx 1 root root 12 Oct 22 15:01 /opt/local/pgsql/lib/libpq.so -> libpq.so.2.2
> lrwxrwxrwx 1 root root 12 Oct 22 15:01 /opt/local/pgsql/lib/libpq.so.2 -> libpq.so.2.2
> -rwxr-xr-x 1 root root 70037 Oct 17 2001 /opt/local/pgsql/lib/libpq.so.2.1
> -rwxr-xr-x 1 root root 79911 Oct 22 15:01 /opt/local/pgsql/lib/libpq.so.2.2
>
>
> I also added the pglib-path to my ld.so.conf and I also copied the
> above libraries to my "normal" lib-path (/usr/local/lib)
>
I assume you ran ldconfig after changing ld.so.conf (although I don't
think this is the problem).
> I also played around with trailing slashes and that stuff.
>
>
> My tcl-version is a recent one (8.3) and I couldnt find any older
> non-beta-pgaccess versions. Somewhere they say only 7.2.1 and 7.2.2
> is supported but I'm sure they just didnt know about 7.2.3 when
> writing it on the wiki-web at www.pgaccess.org ;)
>
It should work with 7.2.3. Part of the problem is that the error message
you got is too generic. It is printed if PGA can not load the shared lib
(which it assumes is because it can't be found).
Do you happen to have multiple versions of Tcl installed on your
computer? If I remember correctly, libpgtcl is not built with stubs
enabled, so you need to make sure you get the correct Tcl version. Other
then that, I am not sure what is going on.
Also, what are the permissions on the lib directory?
If you want, you can add some debugging statements, and send me the
output:
in pgaccess.tcl search for the line
if {[catch {load ${libpgtclpath}[info sharedlibextension]}]} {
change this to:
if {[catch {load ${libpgtclpath}[info sharedlibextension]} err]} {
and then add a line right after it:
puts "ERROR MSG: $err"
Then send me the output after running pgaccess...
--brett
p.s. Which Linux distro?
--
Brett Schwarz
brett_schwarz AT yahoo.com
thnx a lot,
things were getting much clearer (and I finally solved the issue) when
I included your debugstatement.
---------
# pgaccess peter
...
ERROR MSG: couldn't load file "/usr/lib/libpgtcl.so": /usr/lib/libpgtcl.so: cannot open shared object file: No such
fileor directory
...
------
so pgaccess looks in /usr/lib which is the wrong location, even when I
definitely set the correct location in PGLIB. I then altered the
pgaccess.tcl-file to override the default-setting /usr/lib for PGLIB
and I still got the same error.
When looking at the script more closely it stroke me like lightening ;)
The script stores its values in ~/.pgaccess/pgaccess.env the first
time, including PGLIB. So if one calls the script the first time
without PGLIB set (which is what I did) then the defaultvalue /usr/lib
is set and stored in the env-file. Whatever one does later, the
script always reads it values from the env-file.
So I simply had to change the env-file and set PGLIB to the correct
location and now I finally have the piece of software that will make
my work so much easier, cause I can edit my databases without needing
MS access any more.
yeah !! thnx a lot for your help and for anyone who wrote on this
great tool.
peter :)
On Tue, Oct 22, 2002 at 07:49:33AM -0700, Brett Schwarz wrote:
> On Tue, 2002-10-22 at 06:51, pilsl@goldfisch.at wrote:
> > I compiled postgres 7.2.3 (--with-tcl) and newest pgacess (0.98.8.b2).
> >
> > While I got the libpgctl-libraries in the expected place and exported the
> > PGLIB-variable I still get the error:
> >
> > Error: can not find libpgtcl.so shared library.
> >
> > # ls -l $PGLIB/libpgt*
> > -rw-r--r-- 1 root root 31554 Oct 22 15:01 /opt/local/pgsql/lib/libpgtcl.a
> > lrwxrwxrwx 1 root root 15 Oct 22 15:01 /opt/local/pgsql/lib/libpgtcl.so -> libpgtcl.so.2.2
> > lrwxrwxrwx 1 root root 15 Oct 22 15:01 /opt/local/pgsql/lib/libpgtcl.so.2 -> libpgtcl.so.2.2
> > -rwxr-xr-x 1 root root 36151 Oct 22 15:01 /opt/local/pgsql/lib/libpgtcl.so.2.2
> > # ls -l $PGLIB/libpq*
> > -rw-r--r-- 1 root root 87764 Oct 22 15:01 /opt/local/pgsql/lib/libpq.a
> > lrwxrwxrwx 1 root root 12 Oct 22 15:01 /opt/local/pgsql/lib/libpq.so -> libpq.so.2.2
> > lrwxrwxrwx 1 root root 12 Oct 22 15:01 /opt/local/pgsql/lib/libpq.so.2 -> libpq.so.2.2
> > -rwxr-xr-x 1 root root 70037 Oct 17 2001 /opt/local/pgsql/lib/libpq.so.2.1
> > -rwxr-xr-x 1 root root 79911 Oct 22 15:01 /opt/local/pgsql/lib/libpq.so.2.2
> >
> >
> > I also added the pglib-path to my ld.so.conf and I also copied the
> > above libraries to my "normal" lib-path (/usr/local/lib)
> >
>
> I assume you ran ldconfig after changing ld.so.conf (although I don't
> think this is the problem).
>
> > I also played around with trailing slashes and that stuff.
> >
> >
> > My tcl-version is a recent one (8.3) and I couldnt find any older
> > non-beta-pgaccess versions. Somewhere they say only 7.2.1 and 7.2.2
> > is supported but I'm sure they just didnt know about 7.2.3 when
> > writing it on the wiki-web at www.pgaccess.org ;)
> >
> It should work with 7.2.3. Part of the problem is that the error message
> you got is too generic. It is printed if PGA can not load the shared lib
> (which it assumes is because it can't be found).
>
> Do you happen to have multiple versions of Tcl installed on your
> computer? If I remember correctly, libpgtcl is not built with stubs
> enabled, so you need to make sure you get the correct Tcl version. Other
> then that, I am not sure what is going on.
>
> Also, what are the permissions on the lib directory?
>
> If you want, you can add some debugging statements, and send me the
> output:
>
> in pgaccess.tcl search for the line
> if {[catch {load ${libpgtclpath}[info sharedlibextension]}]} {
>
> change this to:
> if {[catch {load ${libpgtclpath}[info sharedlibextension]} err]} {
>
> and then add a line right after it:
> puts "ERROR MSG: $err"
>
> Then send me the output after running pgaccess...
>
>
> --brett
>
> p.s. Which Linux distro?
>
> --
> Brett Schwarz
> brett_schwarz AT yahoo.com
>
--
mag. peter pilsl
IT-Consulting
tel: +43-699-1-3574035
fax: +43-699-4-3574035
pilsl@goldfisch.at
hi i have got a lot of file which is create DEBUG: recycled transaction log file 0000000100000037 DEBUG: recycled transaction log file 0000000100000038 DEBUG: recycled transaction log file 0000000100000039 DEBUG: recycled transaction log file 000000010000003A DEBUG: recycled transaction log file 000000010000003B DEBUG: recycled transaction log file 000000010000003C why is it create? and what is this folder? pg_xlog how i can reduce the number of this files because it takes a lot of place thanks
On Tuesday 05 Nov 2002 8:56 am, Florian Litot wrote: > hi > i have got a lot of file which is create > DEBUG: recycled transaction log file 0000000100000037 > DEBUG: recycled transaction log file 0000000100000038 > DEBUG: recycled transaction log file 0000000100000039 > DEBUG: recycled transaction log file 000000010000003A > DEBUG: recycled transaction log file 000000010000003B > DEBUG: recycled transaction log file 000000010000003C > why is it create? > and what is this folder? pg_xlog > how i can reduce the number of this files because it takes a lot of place > thanks PG writes all transactions to disk before actually making changes so that you can recover in the event of a crash. It splits this transaction log into chunks and recycles them when all the transactions it refers to are no longer of interest. Read up on WAL for more details and configuration options in the postgresql.conf file. -- Richard Huxton
At 11:47 05/11/02, Richard Huxton wrote: >PG writes all transactions to disk before actually making changes so that you >can recover in the event of a crash. It splits this transaction log into >chunks and recycles them when all the transactions it refers to are no longer >of interest. but the problem is it never recycle this file so i have a got a px_log 2Go how i can resolve this problem? why it doesn't recycle?
On Tuesday 05 Nov 2002 11:14 am, Florian Litot wrote: > At 11:47 05/11/02, Richard Huxton wrote: > >PG writes all transactions to disk before actually making changes so that > > you can recover in the event of a crash. It splits this transaction log > > into chunks and recycles them when all the transactions it refers to are > > no longer of interest. > > but the problem is it never recycle this file so i have a got a px_log 2Go > how i can resolve this problem? > why it doesn't recycle? According to the log you posted it was being recycled. How many files are there in pg_xlog and what dates do they have? What are the WAL settings in your postgresql.conf file? Do you have any clients that have been running a long time? -- Richard Huxton
At 12:47 05/11/02, Richard Huxton wrote: >On Tuesday 05 Nov 2002 11:14 am, Florian Litot wrote: > > At 11:47 05/11/02, Richard Huxton wrote: > > >PG writes all transactions to disk before actually making changes so that > > > you can recover in the event of a crash. It splits this transaction log > > > into chunks and recycles them when all the transactions it refers to are > > > no longer of interest. > > > > but the problem is it never recycle this file so i have a got a px_log 2Go > > how i can resolve this problem? > > why it doesn't recycle? > >According to the log you posted it was being recycled. > >How many files are there in pg_xlog and what dates do they have? >What are the WAL settings in your postgresql.conf file? >Do you have any clients that have been running a long time? > >-- > Richard Huxton > >---------------------------(end of broadcast)--------------------------- >TIP 3: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to majordomo@postgresql.org so that your >message can get through to the mailing list cleanly i have got 66 files i have got a new file to 16 minutes # # Write-ahead log (WAL) # wal_files = 64 # range 0-64 #wal_sync_method = fsync # the default varies across platforms: # # fsync, fdatasync, open_sync, or open_datasync #wal_debug = 0 # range 0-16 #commit_delay = 0 # range 0-100000 #commit_siblings = 5 # range 1-1000 #checkpoint_segments = 3 # in logfile segments (16MB each), min 1 #checkpoint_timeout = 300 # in seconds, range 30-3600 #fsync = true it's standard i make some insertion i make 1 insertion every 2 seconds
On Tuesday 05 Nov 2002 12:48 pm, Florian Litot wrote: > At 12:47 05/11/02, Richard Huxton wrote: > >How many files are there in pg_xlog and what dates do they have? > >What are the WAL settings in your postgresql.conf file? > >Do you have any clients that have been running a long time? > i have got 66 files > i have got a new file to 16 minutes > wal_files = 64 # range 0-64 > #wal_sync_method = fsync # the default varies across platforms: > # # fsync, fdatasync, open_sync, or open_datasync > #wal_debug = 0 # range 0-16 > #commit_delay = 0 # range 0-100000 > #commit_siblings = 5 # range 1-1000 > #checkpoint_segments = 3 # in logfile segments (16MB each), min 1 > #checkpoint_timeout = 300 # in seconds, range 30-3600 > #fsync = true > > it's standard > i make some insertion i make 1 insertion every 2 seconds I don't think I can explain better than by quoting from the manual (for the full details see the WAL implementation and configuration sections): "The number of 16MB segment files will always be at least WAL_FILES + 1, and will normally not exceed WAL_FILES + MAX(WAL_FILES, CHECKPOINT_SEGMENTS) + 1. This may be used to estimate space requirements for WAL. Ordinarily, when an old log segment files are no longer needed, they are recycled (renamed to become the next sequential future segments). If, due to a short-term peak of log output rate, there are more than WAL_FILES + MAX(WAL_FILES, CHECKPOINT_SEGMENTS) + 1 segment files, then unneeded segment files will be deleted instead of recycled until the system gets back under this limit. (If this happens on a regular basis, WAL_FILES should be increased to avoid it. Deleting log segments that will only have to be created again later is expensive and pointless.) " Given a wal_files setting of 64 you're always going to have 65 files. Keep an eye on it and see if the number of files keeps increasing - if not, you don't have a problem. If you want to reduce the number of files, reduce wal_files. -- Richard Huxton
At 12:47 05/11/02, Richard Huxton wrote: >On Tuesday 05 Nov 2002 11:14 am, Florian Litot wrote: > > At 11:47 05/11/02, Richard Huxton wrote: > > >PG writes all transactions to disk before actually making changes so that > > > you can recover in the event of a crash. It splits this transaction log > > > into chunks and recycles them when all the transactions it refers to are > > > no longer of interest. > > > > but the problem is it never recycle this file so i have a got a px_log 2Go > > how i can resolve this problem? > > why it doesn't recycle? > >According to the log you posted it was being recycled. > >How many files are there in pg_xlog and what dates do they have? >What are the WAL settings in your postgresql.conf file? >Do you have any clients that have been running a long time? > >-- > Richard Huxton when this files is recycling? because my database is always connecting what can i do?
On Tuesday 05 Nov 2002 4:11 pm, you wrote: > At 12:47 05/11/02, Richard Huxton wrote: > > > but the problem is it never recycle this file so i have a got a px_log > > > 2Go how i can resolve this problem? > > > why it doesn't recycle? > > > >According to the log you posted it was being recycled. > > > >How many files are there in pg_xlog and what dates do they have? > >What are the WAL settings in your postgresql.conf file? > >Do you have any clients that have been running a long time? > > > >-- > > Richard Huxton > > when this files is recycling? > because my database is always connecting > what can i do? As long as the number of files isn't increasing, all is well. The only reason old files wouldn't get recycled is if a client might refer to a transaction held in it. It doesn't matter if you have lots of clients running lots of queries, the files will still get recycled. See my previous reply for why you have 66 files. -- Richard Huxton
the number of files increase my database is always connected i use a jdbc driver and a program is always connected to the database and send sometimes insertion hav you got an idea? At 17:57 05/11/02, Richard Huxton wrote: >On Tuesday 05 Nov 2002 4:11 pm, you wrote: > > At 12:47 05/11/02, Richard Huxton wrote: > > > > but the problem is it never recycle this file so i have a got a px_log > > > > 2Go how i can resolve this problem? > > > > why it doesn't recycle? > > > > > >According to the log you posted it was being recycled. > > > > > >How many files are there in pg_xlog and what dates do they have? > > >What are the WAL settings in your postgresql.conf file? > > >Do you have any clients that have been running a long time? > > > > > >-- > > > Richard Huxton > > > > when this files is recycling? > > because my database is always connecting > > what can i do? > >As long as the number of files isn't increasing, all is well. The only reason >old files wouldn't get recycled is if a client might refer to a transaction >held in it. It doesn't matter if you have lots of clients running lots of >queries, the files will still get recycled. > >See my previous reply for why you have 66 files. > >-- > Richard Huxton > >---------------------------(end of broadcast)--------------------------- >TIP 4: Don't 'kill -9' the postmaster
> the number of files increase > my database is always connected > i use a jdbc driver and a program is always connected to the database > and send sometimes insertion > hav you got an idea? The only thing I know of that can cause this is an old transaction still being required because a connected client might need it. Could this be the case? I don't know what version of PG you are using, but recent ones let you see what queries are in progress via the statistics views. See pg_stat... in the manual and the mailing list archives. It's evening here, so I'll post again tomorrow. -- Richard Huxton