Re: [BUGS] Various bugs with PG7.1 8th March snapshot on Solaris 8 INTEL

[Justin Clift]

Hi Tom,

Sorry for taking so long to get back to this stuff.  Being busy in Life.

Has anything else regarding general broken int8 tests been found out,
with regards to it being caused by OpenSSL.  If that's the case
shouldn't we ask the OpenSSL guys about known issues, or at least let
them know that something may be wrong?

They're up to beta2 of their next release so now's probably the time to
work things out.

Regards and best wishes,

Justin Clift

Tom Lane wrote:
> 
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Justin Clift writes:
> >> In the regression test side of things, Solaris 8 INTEL seems be having
> >> troubles with handling int8 types.  Not sure if this is a known
> >> problem.  The int8 tests failed with error messages like :
> >>
> >> INSERT INTO INT8_TBL VALUES('123','4567890123456789');
> >> + ERROR:  int8 value out of range: "4567890123456789"
> 
> > Ugh.  Did configure detect a working 64 bit integer?
> 
> IIRC, someone else reported a few days ago that the int8 tests failed on
> their platform if and only if openssl was linked in.  Not sure what
> openssl could be doing to screw up long long int arithmetic, but that
> was the report.
> 
> regards, tom lane
> 
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
 - Indira Gandhi

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [BUGS] Various bugs with PG7.1 8th March snapshot on Solaris 8INTEL

[Justin Clift]

Hi Peter,

Can't this be at least worked around by ./configure detecting there will
be a conflict (i.e. being compiled with OpenSSL support on Solaris or
Unixware) then creating something like #define
OPENSSL_DES_ENCRYPT_NAMESPACE_CONFLICT in the Makefile, and then having
crypt.c (etc) check for this and not #include  ?

Things compile fine without  being included, in the case of
OpenSSL support being needed.  As the problem appears to be in
already-released versions of OpenSSL, wouldn't the best approach be to
notify the OpenSSL guys (they're decent people, and CC'ing this now to
their developer list) and also work around the problem ourselves?

Regards and best wishes,

+ Justin Clift

Peter Eisentraut wrote:
> 
> Justin Clift writes:
> 
> > When --with-openssl= is given to configure
> > on Solaris 8 INTEL, the compilation errors in :
> 
> This is an OpenSSL namespace problem on some platforms (Solaris, Unixware
> so far).  Nothing we can really do about it.

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [BUGS] Various bugs with PG7.1 8th March snapshot on Solaris 8INTEL

[Peter Eisentraut]

Justin Clift writes:

> Has anything else regarding general broken int8 tests been found out,
> with regards to it being caused by OpenSSL.  If that's the case
> shouldn't we ask the OpenSSL guys about known issues, or at least let
> them know that something may be wrong?

This has been fixed.  It was a linker problem.

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

[BUGS] --enable-perl doesn't like Solaris

[pgsql-bugs]

Justin Clift ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.

Short Description
--enable-perl doesn't like Solaris

Long Description
When testing which 7.1RC1 options are working on Solaris 8 SPARC, I've come across 
this when using --enable-perl.

It appears that the ./configure script is defining -KPIC somewhere in the perl 
interface stuff, and this is causing the "make" to bomb out.  I'm pretty sure from 
memory that -KPIC is not something that gcc on Solaris likes, and will need to be 
-fPIC -shared or something else.

Please note, on this system 'cc' is a soft link to gcc, for those times I forget to 
set CC (like this time).

Sample Code
./configure --p=/opt/postgresql71 --enable-syslog --with-openssl=/opt/openssl 
--with-python --with-perl



make[3]: Leaving directory 
`/archive/install/postgresql-7.1RC1/src/interfaces/libpgeasy'
make[3]: Entering directory `/archive/install/postgresql-7.1RC1/src/interfaces/perl5'
make -C ../../../src/interfaces/libpq all
make[4]: Entering directory `/archive/install/postgresql-7.1RC1/src/interfaces/libpq'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/archive/install/postgresql-7.1RC1/src/interfaces/libpq'
make -f Makefile all
make[4]: Entering directory `/archive/install/postgresql-7.1RC1/src/interfaces/perl5'
cc -c -I../libpq -I../../include  -xO3 -xdepend-DVERSION=\"1.8.0\" 
-DXS_VERSION=\"1.8.0\" -KPIC -I/usr/perl5/5.00503/sun4-solaris/CORE  Pg.c
cc: unrecognized option `-KPIC'
cc: language depend not recognized
cc: Pg.c: linker input file unused since linking not done
Running Mkbootstrap for Pg ()
chmod 644 Pg.bs
LD_RUN_PATH="/archive/install/postgresql-7.1RC1/src/interfaces/perl5/../libpq" cc -o 
blib/arch/auto/Pg/Pg.so 
-R/archive/install/postgresql-7.1RC1/src/interfaces/perl5/../libpq -G Pg.o
-L/archive/install/postgresql-7.1RC1/src/interfaces/perl5/../libpq -lpq 
cc: Pg.o: No such file or directory
make[4]: *** [blib/arch/auto/Pg/Pg.so] Error 1
make[4]: Leaving directory `/archive/install/postgresql-7.1RC1/src/interfaces/perl5'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/archive/install/postgresql-7.1RC1/src/interfaces/perl5'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/archive/install/postgresql-7.1RC1/src/interfaces'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/archive/install/postgresql-7.1RC1/src'
make: *** [all] Error 2
$ 

No file was uploaded with this report


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [BUGS] --enable-perl doesn't like Solaris

[Peter Eisentraut]

> Justin Clift ([EMAIL PROTECTED]) reports a bug with a severity of 3

> It appears that the ./configure script is defining -KPIC somewhere in
> the perl interface stuff, and this is causing the "make" to bomb out.
> I'm pretty sure from memory that -KPIC is not something that gcc on
> Solaris likes, and will need to be -fPIC -shared or something else.

The Perl build environment is not provided by us, it comes from the
ExtUtils::MakeMaker module.  MakeMaker is misdesigned in that it assumes
that the user will use the same compiler for building his modules as the
one he used for building perl itself.  So if you got Perl from Sun, then
it's likely to have been compiled by Sun's cc.

Solution 1 is to hack MakeMaker and/or the Makefile it generates to fix
the options.  (Replacing -KPIC by -fPIC might do.)

Solution 2 is to recompile Perl with gcc.  This would also give you a
chance to build a shared libperl, so you can use PL/Perl.

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

[BUGS] Python and OpenSSL don't work together

[pgsql-bugs]

Justin Clift ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.

Short Description
Python and OpenSSL don't work together

Long Description
Hi,

When testing which ./configure options work, I've just discovered that something in 
the ./configure process generates the incorrect options when with --with-python and 
--with-openssl are given, such that the python interface doesn't find the openssl 
headers when it wants them.

OpenSSL is definitely compiled and working correctly in /opt/openssl, and the ssl.h 
file is truly at /opt/openssl/include/openssl/ssl.h

Please see the attached code for what I mean (below).



Sample Code
./configure --p=/opt/postgresql71 --enable-syslog --with-openssl=/opt/openssl 
--with-python --with-perl


make[4]: Entering directory `/archive/install/postgresql-7.1RC1/src/interfaces/libpq'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/archive/install/postgresql-7.1RC1/src/interfaces/libpq'
make -f Makefile all
make[4]: Entering directory `/archive/install/postgresql-7.1RC1/src/interfaces/perl5'
make[4]: Leaving directory `/archive/install/postgresql-7.1RC1/src/interfaces/perl5'
make[3]: Leaving directory `/archive/install/postgresql-7.1RC1/src/interfaces/perl5'
make[3]: Entering directory `/archive/install/postgresql-7.1RC1/src/interfaces/python'
make -C ../../../src/interfaces/libpq all
make[4]: Entering directory `/archive/install/postgresql-7.1RC1/src/interfaces/libpq'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/archive/install/postgresql-7.1RC1/src/interfaces/libpq'
make -f Makefile
make[4]: Entering directory `/archive/install/postgresql-7.1RC1/src/interfaces/python'
gcc   -I../../../src/interfaces/libpq -I../../../src/include -g -O2 
-I/usr/local/include/python1.5 -I/usr/local/include/python1.5 -DHAVE_CONFIG_H -c 
./pgmodule.c
In file included from ./pgmodule.c:31:
../../../src/interfaces/libpq/libpq-fe.h:29: openssl/ssl.h: No such file or directory
make[4]: *** [pgmodule.o] Error 1
make[4]: Leaving directory `/archive/install/postgresql-7.1RC1/src/interfaces/python'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/archive/install/postgresql-7.1RC1/src/interfaces/python'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/archive/install/postgresql-7.1RC1/src/interfaces'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/archive/install/postgresql-7.1RC1/src'
make: *** [all] Error 2
$ 

No file was uploaded with this report


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [BUGS] Various bugs with PG7.1 8th March snapshot on Solaris 8 INTEL

[Tom Lane]

Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Justin Clift writes:
>> Has anything else regarding general broken int8 tests been found out,
>> with regards to it being caused by OpenSSL.  If that's the case
>> shouldn't we ask the OpenSSL guys about known issues, or at least let
>> them know that something may be wrong?

> This has been fixed.  It was a linker problem.

We think, anyway.  At least we found a plausible mechanism for the
failure...

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [BUGS] Python and OpenSSL don't work together

[Tom Lane]

> Justin Clift ([EMAIL PROTECTED]) reports a bug with a severity of 3
> When testing which ./configure options work, I've just discovered that something in 
>the ./configure process generates the incorrect options when with --with-python and 
>--with-openssl are given, such that the python interface doesn't find the openssl 
>headers when it wants them.

Looks like interface/python's GNUmakefile and Setup.in.raw need to
cooperate to pass additional -I fields to the compiler.  Perhaps

-e 's%@INCLUDES@%$(filter -I%, $(CPPFLAGS))%g' \

in GNUmakefile and the obvious thing in Setup.in.raw.  Would this allow
removing either of the explicit -I switches in Setup.in.raw?

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [BUGS] Various bugs with PG7.1 8th March snapshot on Solaris 8INTEL

[Larry Rosenman]

* Justin Clift <[EMAIL PROTECTED]> [010325 07:34]:
> Hi Peter,
> 
> Can't this be at least worked around by ./configure detecting there will
> be a conflict (i.e. being compiled with OpenSSL support on Solaris or
> Unixware) then creating something like #define
> OPENSSL_DES_ENCRYPT_NAMESPACE_CONFLICT in the Makefile, and then having
> crypt.c (etc) check for this and not #include  ?
> 
> Things compile fine without  being included, in the case of
> OpenSSL support being needed.  As the problem appears to be in
> already-released versions of OpenSSL, wouldn't the best approach be to
> notify the OpenSSL guys (they're decent people, and CC'ing this now to
> their developer list) and also work around the problem ourselves?
I've been in contact with an OpenSSL guy, and given him a shell
account here.  He's looking into it.

LER

> 
> Regards and best wishes,
> 
> + Justin Clift
> 
> Peter Eisentraut wrote:
> > 
> > Justin Clift writes:
> > 
> > > When --with-openssl= is given to configure
> > > on Solaris 8 INTEL, the compilation errors in :
> > 
> > This is an OpenSSL namespace problem on some platforms (Solaris, Unixware
> > so far).  Nothing we can really do about it.
> 
> ---(end of broadcast)---
> TIP 4: Don't 'kill -9' the postmaster
-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl

[BUGS] creating a pgconnection (or pgdatabase) object on the heap gives segmentation fault...

[ravindranathm]

Hi...
 
find the following details about the bug and please 
send a response/bugfix.
 
--
Testing platform details...
    Postgress 
Version        :    
7.0.3
    
Platform   :    
Linux 6.2 on a Compaq Server
    System 
Memory   :    
1 GB
    Disk 
Space  :    
6 GB
    
library  :    
libpq++
 
Bug description...
1    - Try to create a PgConnection object or a PgDatabase 
object on the heap using new
        
    PgDatabase *conn = new PgDatabase ("user=xyz 
dbname=abc");
        
    or
        
    PgConnection *conn = new PgConnection ("user=xyz 
dbname=abc");
 
    Execute the program after 
compiling.  When the above is executed you get the following 
error:
        
    Segmentation fault (core 
dumped)
 
    Note:  If you create on the 
stack using         

        
    PgDatabase conn = PgDatabase ("user=xyz 
dbname=abc");
        
    or
        
    PgConnection conn = PgConnection ("user=xyz 
dbname=abc");
        
    then, it works.
 
 
2.    - No default constructor 
available for connection object
        
    A call like
        
        PgDatabase conn = 
PgConnection;
        
    will not compile and gives an error message 
saying...    
        
        PgDatabase::PgDatabase() is 
protected.
 
        Therefore, If 
one wants to create an array of connections, (for ex: to implement a connection 
pool),
a 
call like PgConnection conns[CONNECTIONS]; won;t 
work.
 
 
To overcome the above 2 problems, we tried creating 
a class by inheriting from pgDatabase, which provides a 
default constructor.
ex:
    class mydb : public 
PgDatabase {
        
public:
        
    mydb() : PgDatabase() { }
mydb(string& 
constr) : PgDtabase (constr.c_str()) { }
    };
 
Then the function calls:
    mydb* con1 = new 
mydb();
    mydb* con2 = new 
mydb("user=xyz dbname=abc");
are working properly...
but...
    then the calls to free the 
memory give segmentation fault.
        delete 
con1;
        delete 
con2;
 
 
Please kindly, check the above and let me know that 
my analysis is correct or wrong.
In previous version of postgres i.e. 6.x, 
this problem does not exist. Also find
herewith attached some sample code, we used 
for testing...
 
 
sincerely...
 
Ravindranath M
 
 
 pgtest.cpp


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [BUGS] Tests randomly failed

[Alexander Klimov]

On Thu, 22 Mar 2001, Peter Eisentraut wrote:

> In src/test/regress/pg_regress[.sh], line 163, change
> 
> *-*-qnx* | *beos*)
> 
> to
> 
> *-*-qnx* | *beos* | *solaris*)
> 
> and rerun the tests.  This will avoid using Unix domain sockets, which are
> broken on Solaris.

Yes, it works now:
==
 All 76 tests passed. 
==

>From the other hand, my production version uses Unix domain sockets
without problems

Regards,
ASK


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl

[BUGS] bug with identd autentication

[BLON Sébastien]

Hi

The postmaster backend seems to be blocked when the identd server of the peer
accepts the connection but does not respond. (ie if the load is too high
on the identd server for example)

In fact, identd is dying without closing the socket. I know that it
is an identd problem ( pident 3.012 )

The identification seems to be performed by the parent process,
not by a child. Postgres stops forking and does not accept
connections anymore. (See strace below)

The timeout seems to be not configurable.

If posgtres is not restarted or if we do not wait for 5 minutes or
more, Postgres keeps blocking.

I hope i am clear enough.

select(6, [3 4 5], [], NULL, NULL)  = 1 (in [5])
SYS_175(0x2, 0x8197260, 0, 0x8, 0x2)= 0
read(5, "\0\0\1(", 4)   = 4
SYS_175(0x2, 0x81971e0, 0, 0x8, 0x2)= 0
select(6, [3 4 5], [], NULL, NULL)  = 1 (in [5])
SYS_175(0x2, 0x8197260, 0, 0x8, 0x2)= 0
read(5, "\0\2\0\0sintes\0\0\0\0\0\0\0\0\0"..., 292) = 292
open("/home/postgres/pg_hba", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/postgres/pg_hba.conf", O_RDONLY) = 6
fstat(6, {st_mode=S_ISVTX|0263, st_size=0, ...}) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x400150
00
read(6, "#\n# Example PostgreSQL host acc"..., 4096) = 4096
read(6, "USERAUTH are not allowed.\n\n# F"..., 4096) = 2597
close(6)= 0
munmap(0x40015000, 4096)= 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6
bind(6, {sin_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("216.167.107.
199")}, 16) = 0
connect(6, {sin_family=AF_INET, sin_port=htons(113), sin_addr=inet_addr("216.167
.107.198")}, 16) = 0
send(6, "1920,5432\n", 10, 0)   = 10
recv(6,




-- 
Sébastien BLON - Technicien Réseaux - [EMAIL PROTECTED]
Nfrance Conseil - 4 Rue J.F Kennedy - 31000 - Toulouse
Phone : +33 5 34 455 502 http://www.nfrance.com   Fax : +33 5 34 455 507

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

[BUGS] 7.1b6 Compile fail on cygwin with --enable-cassert

[Henshall, Stuart - WCP]

severity: FYI
uname -srm
CYGWIN_98-4.10 1.1.7(0.31/3/2) i586
Spec:
win98SE, PIII 733MHz, 64MB
If configured with ./configure --enable-cassert
then there is an error while makeing:
$make

gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations  -I.
-I../../../../src/include -I/usr/local/include  -c -o pl_funcs.o pl_funcs.c
dlltool --export-all --output-def plpgsql.def pl_parse.o pl_handler.o
pl_comp.o pl_exec.o pl_funcs.o
dllwrap -o plpgsql.dll --dllname plpgsql.dll --def plpgsql.def pl_parse.o
pl_handler.o pl_comp.o pl_exec.o pl_funcs.o ../../../../src/utils/dllinit.o
-L../../../../src/backend -lpostgres -lcygipc -lcygwin -lcrypt -lkernel32 
pl_exec.o(.text+0x709):pl_exec.c: undefined reference to `assert_enabled'
pl_exec.o(.text+0x730):pl_exec.c: undefined reference to `FailedAssertion'
collect2: ld returned 1 exit status
dllwrap: gcc exited with status 1
make[4]: *** [libplpgsql.a] Error 1
make[4]: Leaving directory `/usr/src/postgresql-7.1beta6/src/pl/plpgsql/src'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/usr/src/postgresql-7.1beta6/src/pl/plpgsql'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/src/postgresql-7.1beta6/src/pl'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/postgresql-7.1beta6/src'
make: *** [all] Error 2

Full configure output:
 <> 
Full Make Output:
 <> 
-Stuart

[Side FYI:
I had an error with the bug reporting tool:
1: Gave a to large code example (over 8140 - upgrade to 7.1)
2: Went Back and erased the bottom box + made couple of alteration to the
long version and re submitted.
It seem both sent an entry as anonymous (with one being empty) 
]


 enbl_casrt_cnf.out
 enbl_casrt_mk.out


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

[BUGS] Odd 'except' and 'default' interaction behavior

[phil]

We noticed a strange behavior involving 'except' and 'default'
interaction.  Example from psql:

wpbb=# \d robtest
  Table "robtest"
 Attribute |  Type   |  Modifier   
---+-+-
 id| integer | default '1'
 userid| integer | 
 articleid | integer | 

wpbb=# insert into robtest (userid,articleid) select '1'::int4,'2'::int4 except select 
'2'::int4,'5'::int4;
ERROR:  Each UNION | EXCEPT | INTERSECT query must have the same number of columns.

wpbb=# alter table robtest alter column id drop default;
ALTER

wpbb=# insert into robtest (userid,articleid) select '1'::int4,'2'::int4 except select 
'2'::int4,'5'::int4;
INSERT 306530 1


Notice that error regarding the usage of except and the # of columns. 
Strange.  Yet, that exact same query works fine when we remove a
default on a column on the table which isn't being referenced. 

I'm not sure if this is a bug, a poorly written error message, or my
ignorance. :')  We are using Postgresql 7.0.3 release under Linux:

phil=# select version();
version 

 PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc 2.7.2.3 (1 row)


Thanks!!


Phil

-- 
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR
   [EMAIL PROTECTED] -- http://www.netroedge.com/~phil
 PGP F16: 01 D2 FD 01 B5 46 F4 F0  3A 8B 9D 7E 14 7F FB 7A

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [BUGS] Odd 'except' and 'default' interaction behavior

[Tom Lane]

[EMAIL PROTECTED] writes:
> We noticed a strange behavior involving 'except' and 'default'
> interaction.  Example from psql:

This is a known bug.  It's fixed in 7.1.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [BUGS] Tests randomly failed

[Alexander Klimov]

On Thu, 22 Mar 2001, Tom Lane wrote:
> What I see is a lot of
> 
> ! psql: Backend startup failed
> 
> which suggests a fork() failure.  Look in the postmaster logfile to see
> the exact kernel error code --- but probably you are out of swap space
> or up against the kernel's limit on number of processes for one userid.
Strange, but this solution *also* works: I raise in /etc/system from 64 to
set maxuprc=256
revert pg_regress.sh in original state (with unix sockets for solaris),
and now all tests are passed.

Regards,
ASK


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl

Re: [BUGS] Various bugs with PG7.1 8th March snapshot on Solaris 8INTEL

[Larry Rosenman]

* Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> [010325 14:41]:
> From: Larry Rosenman <[EMAIL PROTECTED]>
> 
> ler> * Justin Clift <[EMAIL PROTECTED]> [010325 07:34]:
> ler> > Hi Peter,
> ler> > 
> ler> > Can't this be at least worked around by ./configure detecting there will
> ler> > be a conflict (i.e. being compiled with OpenSSL support on Solaris or
> ler> > Unixware) then creating something like #define
> ler> > OPENSSL_DES_ENCRYPT_NAMESPACE_CONFLICT in the Makefile, and then having
> ler> > crypt.c (etc) check for this and not #include  ?
> ler> > 
> ler> > Things compile fine without  being included, in the case of
> ler> > OpenSSL support being needed.  As the problem appears to be in
> ler> > already-released versions of OpenSSL, wouldn't the best approach be to
> ler> > notify the OpenSSL guys (they're decent people, and CC'ing this now to
> ler> > their developer list) and also work around the problem ourselves?
> ler> I've been in contact with an OpenSSL guy, and given him a shell
> ler> account here.  He's looking into it.
> 
> The problem is how to make it smoothe.  I'm open for suggestions.  And
> it's not as simple as just skipping compilation of des_encrypt() in
> OpenSSL, because it's needed internally.  I've no idea if the bast way
> is really to rename the function or something else.  Just removing it
> from the exported headers is *not* the solution, because there will
> still be a name clash, the only difference being that ld won't make a
> fuss about it, and the OpenSSL implementation will most probably win,
> making those who call it thinking it's the libc ds_encrypt() loosers!
I suspect renaming it would be the best way, since we have 2 major
(SUN, SCO) vendors claiming a des_encrypt() function in their libcrypt
and/or libc. 

LER

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [BUGS] Odd 'except' and 'default' interaction behavior

[Justin Clift]

Hi Phil,

There is a place on the techdocs.postgresql.org website that is purely
for listing gotcha's like this sounds to be.  It's so people NOT running
the very latest and greatest versions of PostgreSQL can be aware of
known things to avoid doing, potentical gotcha's, etc.

Can you tell me more about this strange behaviour?  If it's appropriate,
I'll try to get it onto the techdocs website.

Regards and best wishes,

Justin Clift

Tom Lane wrote:
> 
> [EMAIL PROTECTED] writes:
> > We noticed a strange behavior involving 'except' and 'default'
> > interaction.  Example from psql:
> 
> This is a known bug.  It's fixed in 7.1.
> 
> regards, tom lane
> 
> ---(end of broadcast)---
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
 - Indira Gandhi

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [BUGS] Odd 'except' and 'default' interaction behavior

[Tom Lane]

Justin Clift <[EMAIL PROTECTED]> writes:
> Can you tell me more about this strange behaviour?  If it's appropriate,
> I'll try to get it onto the techdocs website.

The underlying bug is that in

INSERT INTO foo SELECT blah blah FROM bar

the INSERT processing tries to realign the SELECT's target list to match
what the INSERTed tuples need to be.  This may include reordering the
values, adding NULL or default expressions for missing columns, datatype
coercions, etc.

Unfortunately the INSERT code is too stupid to know that when the SELECT
has a top-level UNION, EXCEPT, or INTERSECT operator, there are multiple
target lists that would all need to be adjusted the same way.  It only
changes the first one, leading to funny errors later on.

There are other cases that break too, IIRC, mostly involving GROUP BY
or ORDER BY in the SELECT.

This is all fixed in 7.1 by the simple expedient of using two levels
of target list, so that we don't have to munge the SELECT.

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [BUGS] Various bugs with PG7.1 8th March snapshot on Solaris 8INTEL

[Justin Clift]

That sounds like The Right Way of doing it;  most responsible,
technically sound, etc.

Regards and best wishes,

Justin Clift

Larry Rosenman wrote:

> I suspect renaming it would be the best way, since we have 2 major
> (SUN, SCO) vendors claiming a des_encrypt() function in their libcrypt
> and/or libc.
> 
> LER
> 
> --
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
> US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   [EMAIL PROTECTED]
> Automated List Manager   [EMAIL PROTECTED]

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
 - Indira Gandhi

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

[BUGS] Problem with test results submission form

[Rainer Mager]

I tried to submit the results of my regression tests and got this:

Warning: PostgreSQL query failed: ERROR: parser: parse error at or near "t"
in
/home/projects/pgsql/developers/vev/public_html/regress/regress.php on line
359
Database write failed.


--Rainer


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl

Re: [BUGS] Various bugs with PG7.1 8th March snapshot on Solaris8INTEL

[Richard Levitte - VMS Whacker]

From: Larry Rosenman <[EMAIL PROTECTED]>

ler> * Justin Clift <[EMAIL PROTECTED]> [010325 07:34]:
ler> > Hi Peter,
ler> > 
ler> > Can't this be at least worked around by ./configure detecting there will
ler> > be a conflict (i.e. being compiled with OpenSSL support on Solaris or
ler> > Unixware) then creating something like #define
ler> > OPENSSL_DES_ENCRYPT_NAMESPACE_CONFLICT in the Makefile, and then having
ler> > crypt.c (etc) check for this and not #include  ?
ler> > 
ler> > Things compile fine without  being included, in the case of
ler> > OpenSSL support being needed.  As the problem appears to be in
ler> > already-released versions of OpenSSL, wouldn't the best approach be to
ler> > notify the OpenSSL guys (they're decent people, and CC'ing this now to
ler> > their developer list) and also work around the problem ourselves?
ler> I've been in contact with an OpenSSL guy, and given him a shell
ler> account here.  He's looking into it.

The problem is how to make it smoothe.  I'm open for suggestions.  And
it's not as simple as just skipping compilation of des_encrypt() in
OpenSSL, because it's needed internally.  I've no idea if the bast way
is really to rename the function or something else.  Just removing it
from the exported headers is *not* the solution, because there will
still be a name clash, the only difference being that ld won't make a
fuss about it, and the OpenSSL implementation will most probably win,
making those who call it thinking it's the libc ds_encrypt() loosers!

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \  SWEDEN   \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

[BUGS] Deleting Objects...

[Rolando Lora]

Hi there...

I'm not sure if this is a "bug" or not but I couldn't
find how to deal with it.

For instance if we create a table using "Object ID"
for storing large objects:

> create table picture(id serial, pic_oid oid);

and then we add some data:

> insert into picture 
  (pic_oid) values (lo_import('/tmp/image.jpg'));

We'll insert into the table an "Object Id" pointing to
an external file "xin...OID".

But when we execute:

> delete from picture;

The data contained in the table gets deleted but the
real object "xin...OID" remains untouched when (I
Think) it should be deleted too. Is this a bug?

I'm developing an application where I need to upload a
lot of pictures but when I delete some of them I don't
want files floating around that used to be pictures.

Is there anyway I can deal with it?

Thanks in advance...
--
Rolando Lora
Blackstar Co - Development
Bolivia - South America
--

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [BUGS] Deleting Objects...

[Stephan Szabo]

On Sun, 25 Mar 2001, Rolando Lora wrote:

> Hi there...
> 
> I'm not sure if this is a "bug" or not but I couldn't
> find how to deal with it.
> 
> For instance if we create a table using "Object ID"
> for storing large objects:
> 
> > create table picture(id serial, pic_oid oid);
> 
> and then we add some data:
> 
> > insert into picture 
>   (pic_oid) values (lo_import('/tmp/image.jpg'));
> 
> We'll insert into the table an "Object Id" pointing to
> an external file "xin...OID".
> 
> But when we execute:
> 
> > delete from picture;
> 
> The data contained in the table gets deleted but the
> real object "xin...OID" remains untouched when (I
> Think) it should be deleted too. Is this a bug?
> 
> I'm developing an application where I need to upload a
> lot of pictures but when I delete some of them I don't
> want files floating around that used to be pictures.
> 
> Is there anyway I can deal with it?

Generally speaking I think right now you need to put
a trigger on the table to remove the large objects when
the row is deleted.


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])