Re: [GENERAL] Oracle and Postgresql
On Thu, 4 Sep 2008, Lars Haugseth wrote: http://www.amazon.com/PostgreSQL-Reference-Manual-SQL-Language/dp/0954612027/ref=pd_sim_b_1 Though I mostly use the online version, I'm considering buying these. However, I'm probably going to kill myself if I find a new edition for sale only a short while after I've bought them. They're already one rev off from current and will soon be two. Bruce says he was able to print a one-off for the whole thing for around the same price as that set, and you could print the 8.3 docs instead: http://momjian.us/main/blogs/pgblog.html#January_10_2008_4 -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] recover in single-user backend fails
Hello, When doing a recover in a single-user backend we get the following error: $ postgres -D /var/lib/pgsql/data/ test PANIC: block 24929 unfound Aborted. All this was the result of an unclean postmaster shutdown while running a VACUUM in single-user backend. PGVERSION=8.1.6 DB SIZE= +- 7GB Thank you for the input! Regards, Wouter S.
Re: [GENERAL] large inserts and fsync
On Fri, 5 Sep 2008, Tom Lane wrote: The trouble with turning fsync off is that a system crash midway through the import might leave you with a corrupt database. If you're willing to start over from initdb then okay, but if you are importing into a database that already contains valuable data, I wouldn't recommend it. If you have enough disk space, realistically if you're running with fsync off you should setup enough PITR features to get a base backup first, or just copy the database directory if you can take the server down a bit. Then your worst case becomes just starting over from that backup rather than initdb. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] large inserts and fsync
Yeah, the backup is standard operating procedure before the start of the release process. I'm going to try a few of the suggestions offered here first, then fall back on the fsync option if I can't get an appreciable increase in speed. thanks all for the help and thoughts. -Original Message- From: Greg Smith [mailto:[EMAIL PROTECTED] Sent: Sat 9/6/2008 4:45 AM To: Tom Lane Cc: Aaron Burnett; Sam Mason; pgsql-general@postgresql.org Subject: Re: [GENERAL] large inserts and fsync On Fri, 5 Sep 2008, Tom Lane wrote: > The trouble with turning fsync off is that a system crash midway through > the import might leave you with a corrupt database. If you're willing > to start over from initdb then okay, but if you are importing into a > database that already contains valuable data, I wouldn't recommend it. If you have enough disk space, realistically if you're running with fsync off you should setup enough PITR features to get a base backup first, or just copy the database directory if you can take the server down a bit. Then your worst case becomes just starting over from that backup rather than initdb. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
[GENERAL] Efficient processing of staging data
Dear, I'm looking for an efficient way to process data that I have stored in a staging table. This is syslog output, so it consists of text, where I need regexes to filter it out. The data will be split into several/a lot of tables. I currently have a set of queries that * read from staging and insert into destination table. * delete from staging (using destination table). This requires 2 scans over the tables and the index operations (which pay of here). I do the processing incrementally, in order to keep run time under control. But for only 4 filters this will take around 6 to 30 minutes. My later idea was to do a (incremental) table scan on the staging table and have a function do the processing of the row. The function will then either: * decide to do nothing * decide to insert the (transformed) row into the destination table and delete it from the staging table. An obvious extension would be to put this processing in the INSERT trigger of the staging table, saving the I/O's requires for an insert and delete from the staging table. I like to do this afterwards for the moment. What are the recommended methods and helpful implementation hints to get it working optimally? I.e. would my method work or are there any better solutions possible? How can I write the filtering functions in such a manner that I can later transform the solution in a trigger based one? Regards, - Joris Dobbelsteen -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] PostgreSQL SSL problem
Hi Team, I have problems to setup SSL for PostgreSQL server. I did all the steps which described in the documentation (17.8. Secure TCP/IP Connections with SSL), but when I try to start the PostgreSQL server the pg_ctl gave me: "could not start server". And nothing in the logs (I enabled all of them). I googled around but did not find much. After I disable SSL option in postgresql.conf the server is starting successfully. I have all certificates with proper CA signature, rest of applications (Postfix, Apache, etc.) work with this certificates very well. I am using OpenSSL from ports. Please, advise. My spec: FreeBSD 7.0-RELEASE-p3 amd64 PostgreSQL 8.3.3 (installed from ports): WITH_NLS=true WITHOUT_PAM=true WITHOUT_LDAP=true WITHOUT_MIT_KRB5=true WITHOUT_HEIMDAL_KRB5=true WITHOUT_OPTIMIZED_CFLAGS=true WITH_XML=true WITHOUT_TZDATA=true WITHOUT_DEBUG=true WITH_ICU=true WITH_INTDATE=true $ pg_config BINDIR = /usr/local/bin DOCDIR = /usr/local/share/doc/postgresql INCLUDEDIR = /usr/local/include PKGINCLUDEDIR = /usr/local/include/postgresql INCLUDEDIR-SERVER = /usr/local/include/postgresql/server LIBDIR = /usr/local/lib PKGLIBDIR = /usr/local/lib/postgresql LOCALEDIR = /usr/local/share/locale MANDIR = /usr/local/man SHAREDIR = /usr/local/share/postgresql SYSCONFDIR = /usr/local/etc/postgresql PGXS = /usr/local/lib/postgresql/pgxs/src/makefiles/pgxs.mk CONFIGURE = '--with-libraries=/usr/local/lib' '--with-includes=/usr/local/include' '--enable-thread-safety' '--with-docdir=/usr/local/share/doc/postgresql' '--with-openssl' '--with-system-tzdata=/usr/share/zoneinfo' '--enable-integer-datetimes' '--enable-nls' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd7.0' 'CC=cc' 'CFLAGS=-O2 -fno-strict-aliasing -pipe ' 'LDFLAGS= -pthread -rpath=/usr/local/lib' 'build_alias=amd64-portbld-freebsd7.0' CC = cc CPPFLAGS = -I/usr/local/include CFLAGS = -O2 -fno-strict-aliasing -pipe -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv CFLAGS_SL = -fPIC -DPIC LDFLAGS = -pthread -rpath=/usr/local/lib -L/usr/local/lib -Wl,-R'/usr/local/lib' LDFLAGS_SL = LIBS = -lpgport -lintl -lssl -lcrypto -lz -lreadline -lcrypt -lm VERSION = PostgreSQL 8.3.3 Thanks, Andriy -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] storing repeating dates / events
Hi I want to store dates / events for example birthdays (or may 5th) that repeats every year.. what is the best way to do in postgres? if i use timestamp it is going to be use the current year.. how do i do this?
Re: [GENERAL] storing repeating dates / events
[EMAIL PROTECTED] wrote: Hi I want to store dates / events for example birthdays (or may 5th) that repeats every year.. what is the best way to do in postgres? if i use timestamp it is going to be use the current year.. how do i do this? A timestamp includes the year so there shouldn't be any problem. Although, i can't say i'm sure what you think might be the problem. Perhaps you should clarify what it is you want to store, as well as your concerns. b -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] storing repeating dates / events
Em Saturday 06 September 2008 14:12:49 [EMAIL PROTECTED] escreveu: > Hi > I want to store dates / events for example birthdays (or may 5th) that > repeats every year.. > what is the best way to do in postgres? > if i use timestamp it is going to be use the current year.. how do i do > this? Along with the timestamp store a boolean that indicates if the event should consider the year or not. But you might surely design it better, specially for things that repeat on intervals other than yearly. -- Jorge Godoy <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part.
Re: [GENERAL] storing repeating dates / events
On Sat, Sep 6, 2008 at 10:21 AM, brian <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > >> Hi >> I want to store dates / events for example birthdays (or may 5th) that >> repeats every year.. >> what is the best way to do in postgres? >> if i use timestamp it is going to be use the current year.. how do i do >> this? >> > A timestamp includes the year so there shouldn't be any problem. Although, > i can't say i'm sure what you think might be the problem. Perhaps you should > clarify what it is you want to store, as well as your concerns. if it includes the year, how do i query out and find birthdays for this this year? like if i had a table with column user text, dob timestamp without timezone, can you tell me what the query will be to find todays birthday?
Re: [GENERAL] storing repeating dates / events
On Sat, Sep 6, 2008 at 10:32 AM, Jorge Godoy <[EMAIL PROTECTED]> wrote: > Em Saturday 06 September 2008 14:12:49 [EMAIL PROTECTED] escreveu: > > Hi > > I want to store dates / events for example birthdays (or may 5th) that > > repeats every year.. > > what is the best way to do in postgres? > > if i use timestamp it is going to be use the current year.. how do i do > > this? > Along with the timestamp store a boolean that indicates if the event should > consider the year or not. > > But you might surely design it better, specially for things that repeat on > intervals other than yearly. > yes i am trying to build a alerting system where events will repeat weekly/monthly/annually what is the best way to store this kind of information in postgres? thanks
Re: [GENERAL] Can I truncate statements in the log?
Howard Cole wrote: > As part of my log configuration, I log statements that take over 3 > seconds. I find this very useful for optimising tables etc. The problem > is that it produces verbatim some very large statements which can create > huge log entries, which are probably responsible themselves for slowing > the system down. The problem tend to be insert statements for binary > objects - which can be Megabytes long. > > Is it possible to stop logging these excessive insert statements > somehow, or restricting the log of statements to select, delete etc and > ignore inserts. No, sorry. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] storing repeating dates / events
Em Saturday 06 September 2008 14:34:22 [EMAIL PROTECTED] escreveu: > yes i am trying to build a alerting system where events will repeat > weekly/monthly/annually > > what is the best way to store this kind of information in postgres? Use timestamps. And model your application with them. -- Jorge Godoy <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part.
Re: [GENERAL] Subqueries in Check() -- Still Intentionally Omitted?
Tom Lane wrote: > "Richard Broersma" <[EMAIL PROTECTED]> writes: > > I am curious if the motivation is still valid for intentionally > > omitting check sub-queries. (what was the motivation to begin with?) > > > Since we can effectively work around this limitation by doing the same > > thing with a function in a CHECK constraint, why would we want to > > prevent anyone from using the standard syntax for achieving the same > > effect? > > Because if we supported the standard syntax, we'd also have to support > the standard semantics; which a function-in-CHECK does *not* give you. > > The standard says that the constraint is guaranteed not to be violated, > which in the worst case means that any time you update the table(s) > referenced in the subquery, you have to retest the CHECK expression > at every row of the table having the constraint. Consider for instance > CREATE TABLE t1 (x int CHECK (x < (SELECT sum(y) FROM t2))); > If we change some value of t2.y, do all values of t1.x still satisfy > their constraint? > > In some cases, with enough intelligence you could optimize this into > something fast enough to be usable; but it's a research problem. > (The cases that I can see how to optimize are pretty much equivalent to > plain foreign key constraints, anyway.) Is this a TODO? I assume it is not. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] recover in single-user backend fails
"Wouter Sergeyssels" <[EMAIL PROTECTED]> writes: > When doing a recover in a single-user backend we get the following > error: > $ postgres -D /var/lib/pgsql/data/ test > PANIC: block 24929 unfound This looks like it is probably a case of a design problem that was fixed in 8.2: the WAL replay code wasn't prepared for the case of finding an update record for a page that was since truncated away (or its table was dropped entirely). FWIW, the only exact matches to that message spelling that I can find in the 8.1 sources are in gistxlog.c, so this problem is evidently corruption in a GIST index. Dunno if that information is of any help. But the real problem is that since the recovery is aborting here, no other corrections from WAL are getting applied, so anything else that was changed lately is also at risk. The only recovery strategy that I can think of in 8.1 is to blow away your WAL with pg_resetxlog, let the database come up in a damaged condition, and then try to extract data from it. The best bet would be to try to get a complete pg_dump out of it, and then initdb and reload; since you don't know exactly what's been corrupted, you should not try to go back into production without an initdb/reload. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
I've battled this for a while. I'm finally breaking down and asking for help. If you're answer to this is "why 64-bit" then don't answer. You wouldn't understand. Same if you say "why don't you use packages." Here is my scenerio: - Sun 420R x450Mhz UltraSPARC-II / 4GB RAM - Solaris 10 05/08 - OpenSSL 0.9.8h - PostgreSQL 8.3.3 - GCC 3.4.6 - GNU Make 3.81 OpenSSL configure line (compiles clean and works perfectly): ./Configure shared solaris64-sparcv9-gcc -R/usr/sfw/lib/sparcv9 -R/usr/local/ssl/lib PostgreSQL configure line: ./configure --with-openssl --without-readline CFLAGS="-m64 -mcpu=ultrasparc" CPPFLAGS="-I/usr/local/ssl/include" LDFLAGS="-L/usr/local/ssl/lib -R/usr/local/ssl/lib -R/usr/sfw/lib/sparcv9" If I don't include OpenSSL support, all is fine. This is the error I get during configure using the above flags: checking checking blah blah checking test program... failed configure: error: Could not execute a simple test program. This may be a problem related to locating shared libraries. Check the file 'config.log' for the exact reason. The most glaring error in config.log shows this: configure:5635: gcc -o conftest -m64 -mcpu=ultrasparc -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labe ls -fno-strict-aliasing -fwrapv -I/usr/local/ssl/include -L/usr/local/ssl/lib -R/usr/local/ssl/lib -R/usr/sfw/lib/sparcv9 conftest.c -lutil -lm >&5 ld: fatal: library -lutil: not found ld: fatal: File processing errors. No output written to conftest collect2: ld returned 1 exit status configure:5641: $? = 1 configure: failed program was: | /* confdefs.h. */ Now, if I recall correctly, lutil is part of GLIBC - a Linux-only dev package. Why would it be using this on Solaris? Am I missing the real error or does this have something to do with the overall failure to configure (thus, compile)? Thanks everyone! Randy PS I put the entire config.log here for analysis: http://www.procyonlabs.com/temp/config.log -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
"Randal T. Rioux" <[EMAIL PROTECTED]> writes: > checking checking blah blah > checking test program... failed > configure: error: > Could not execute a simple test program. This may be a problem > related to locating shared libraries. Check the file 'config.log' > for the exact reason. > The most glaring error in config.log shows this: You're looking at the wrong thing --- library-not-found errors are completely expected in config.log, because it has to find out what libraries are present. The actual failure is down here: configure:19839: checking test program configure:19854: gcc -o conftest -m64 -mcpu=ultrasparc -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -I/usr/local/ssl/include -L/usr/local/ssl/lib -R/usr/local/ssl/lib -R/usr/sfw/lib/sparcv9 conftest.c -lssl -lcrypto -lz -lrt -lsocket -lm >&5 configure:19857: $? = 0 configure:19859: ./conftest ld.so.1: conftest: fatal: libgcc_s.so.1: open failed: No such file or directory ./configure: line 19860: 20583 Killed ./conftest$ac_exeext configure:19862: $? = 137 configure: program exited with status 137 Since you say this doesn't happen when SSL support isn't requested, I suppose that the problem has to do with libssl.so attempting to reference libgcc_s.so. Beyond that, hard to say, but I bet there is an rpath problem at the bottom of it. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
On Sat, September 6, 2008 7:05 pm, Tom Lane wrote: > "Randal T. Rioux" <[EMAIL PROTECTED]> writes: >> checking checking blah blah checking test program... >> failed configure: error: Could not execute a simple test program. This >> may be a problem related to locating shared libraries. Check the file >> 'config.log' for the exact reason. > >> The most glaring error in config.log shows this: > > You're looking at the wrong thing --- library-not-found errors are > completely expected in config.log, because it has to find out what > libraries are present. The actual failure is down here: > > configure:19839: checking test program configure:19854: gcc -o conftest > -m64 -mcpu=ultrasparc -Wall -Wmissing-prototypes -Wpointer-arith -Winline > -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing > -fwrapv -I/usr/local/ssl/include -L/usr/local/ssl/lib > -R/usr/local/ssl/lib -R/usr/sfw/lib/sparcv9 conftest.c -lssl -lcrypto > -lz -lrt -lsocket -lm >> &5 > configure:19857: $? = 0 configure:19859: ./conftest ld.so.1: conftest: > fatal: libgcc_s.so.1: open failed: No such file or directory ./configure: > line 19860: 20583 Killed ./conftest$ac_exeext configure:19862: $? = 137 > configure: program exited with status 137 Nice catch - but I can't tell which file open failed? > Since you say this doesn't happen when SSL support isn't requested, I > suppose that the problem has to do with libssl.so attempting to reference > libgcc_s.so. Beyond that, hard to say, but I bet there is an rpath > problem at the bottom of it. Could it be trying to hit the stock OpenSSL libs installed with Solaris, instead of my 64-bit version? I thought the LDFLAGS would have prevented that. Thanks! Randy -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
"Randal T. Rioux" <[EMAIL PROTECTED]> writes: > On Sat, September 6, 2008 7:05 pm, Tom Lane wrote: >> configure:19857: $? = 0 configure:19859: ./conftest ld.so.1: conftest: >> fatal: libgcc_s.so.1: open failed: No such file or directory ./configure: >> line 19860: 20583 Killed ./conftest$ac_exeext configure:19862: $? = 137 >> configure: program exited with status 137 > Nice catch - but I can't tell which file open failed? It looks pretty clear to me that libgcc_s.so.1 was the file that couldn't be found. One question is exactly where that lives on your machine. Presumably it exists someplace, else the build of OpenSSL should've failed. >> Since you say this doesn't happen when SSL support isn't requested, I >> suppose that the problem has to do with libssl.so attempting to reference >> libgcc_s.so. Beyond that, hard to say, but I bet there is an rpath >> problem at the bottom of it. > Could it be trying to hit the stock OpenSSL libs installed with Solaris, > instead of my 64-bit version? I thought the LDFLAGS would have prevented > that. I'm not a Solaris user, but I'd be kinda surprised if Solaris' own libraries were built with gcc --- Sun has their own compiler no? I think it's finding your custom libssl just fine but the subsequent requirement of libgcc_s is somehow not working. ldd or local equivalent might help debug this. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] storing repeating dates / events
[EMAIL PROTECTED] wrote: Hi I want to store dates / events for example birthdays (or may 5th) that repeats every year.. what is the best way to do in postgres? if i use timestamp it is going to be use the current year.. how do i do this? Any anniversary today? SELECT * FROM your_table_with_timestamp_column WHERE EXTRACT(DAY FROM your_column) = EXTRACT(DAY FROM now()) AND EXTRACT(MONTH FROM your_column) = EXTRACT(MONTH FROM now()) AND your_column <= now(); -- prevent to show events that will be in the future Or May 5th: SELECT * FROM your_table_with_timestamp_column WHERE EXTRACT(DAY FROM your_column) = EXTRACT(DAY FROM TIMESTAMP '2008-05-05') AND EXTRACT(MONTH FROM your_column) = EXTRACT(MONTH FROM TIMESTAMP '2008-05-05') AND '2008-05-05'::timestamp <= now(); -- prevent to show events that will be in the future Sorry, if I misunderstood your question. Taras Kopets -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
On Sat, September 6, 2008 8:21 pm, Tom Lane wrote: > "Randal T. Rioux" <[EMAIL PROTECTED]> writes: >> On Sat, September 6, 2008 7:05 pm, Tom Lane wrote: >>> configure:19857: $? = 0 configure:19859: ./conftest ld.so.1: >>> conftest: fatal: libgcc_s.so.1: open failed: No such file or >>> directory ./configure: line 19860: 20583 Killed ./conftest$ac_exeext configure:19862: $? = 137 configure: program exited with status 137 > >> Nice catch - but I can't tell which file open failed? > > It looks pretty clear to me that libgcc_s.so.1 was the file that couldn't > be found. One question is exactly where that lives on your machine. Presumably it exists someplace, else the build of OpenSSL should've failed. That's what I thought - just dismissed it because I know it is there: sh-3.00# find / -name libgcc_s.so.1 /usr/local/lib/libgcc_s.so.1 /usr/local/lib/sparcv9/libgcc_s.so.1 >>> Since you say this doesn't happen when SSL support isn't requested, I >>> suppose that the problem has to do with libssl.so attempting to >>> reference libgcc_s.so. Beyond that, hard to say, but I bet there is an rpath problem at the bottom of it. > >> Could it be trying to hit the stock OpenSSL libs installed with Solaris, instead of my 64-bit version? I thought the LDFLAGS would have prevented that. > > I'm not a Solaris user, but I'd be kinda surprised if Solaris' own libraries were built with gcc --- Sun has their own compiler no? I think it's finding your custom libssl just fine but the subsequent requirement of libgcc_s is somehow not working. ldd or local equivalent might help debug this. bash-3.00# ldd /usr/local/lib/sparcv9/libgcc_s.so.1 libc.so.1 => /lib/64/libc.so.1 libm.so.2 => /lib/64/libm.so.2 /platform/SUNW,Ultra-80/lib/sparcv9/libc_psr.so.1 This is baffling me. Everything seems in place - but something is wrong. What about including OpenSSL support could be doing this? I just compiled Apache 2.2.9 with SSL and it went fine: bash-3.00# file httpd httpd: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped, no debugging information available Thanks, Randy PS Your mail server bounced my message... called me a spammer! :-) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
"Randal T. Rioux" <[EMAIL PROTECTED]> writes: > On Sat, September 6, 2008 8:21 pm, Tom Lane wrote: > ldd or local equivalent might help debug this. > bash-3.00# ldd /usr/local/lib/sparcv9/libgcc_s.so.1 > libc.so.1 => /lib/64/libc.so.1 > libm.so.2 => /lib/64/libm.so.2 > /platform/SUNW,Ultra-80/lib/sparcv9/libc_psr.so.1 How about ldd on the libssl.so you're using? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
