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
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_i
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) t
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
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
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
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
* 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 c
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 pr
[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: subscr
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 |
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
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 )
T
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:
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
* 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_CONF
> 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 interfa
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
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 proc
> 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 lik
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.
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
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 t
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 t
24 matches
Mail list logo
