Applied. Thanks.
[ Charset ISO-8859-1 unsupported, converting... ]
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> |> The Makefile.shlib changes will have to be discussed with other Linux
> |> developers so we are sure it will work on all platforms.
>
> The problem with the current settings i
"Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
>> This bug has probably been there all along, but it'd be pretty
>> low-probability under most circumstances.
> FYI, either postgres 6.3.2 did not have this problem or what I am doing did
> not trigger it in 6.3.2 (I recently upgraded from 6.3
"Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> #2 0xdaa41 in fixedlen_like (
> s=0x1eeff4 "MQZSVRSJDSFR"... , p=0x1bdbe0,
> charlen=12) at like.c:53
> #3 0xdab1d in textlike (s=0x1eeff0, p=0x1bdbe0) at like.c:100
Oooh, I see it ... nasty! fixedlen_like is effectively assuming
On Thu, Jul 06, 2000 at 03:18:59AM -0400, Tom Lane wrote:
> "Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> > What I can do is create a fake dataset, find some values that cause the problem,
>then give
> > that to you. Would that be acceptable?
>
> Sure, if you can do that. I just want
If I declare a cursor in embedded SQL I get a strange error wich
doesn't occur if I declare it manually with psql!
the code is:
void setSQL(PGconn *conn){
PQexec(conn,"SET DATESTYLE=European;");
PQexec(conn,"BEGIN TRANSACTION;");
PQexec(conn,"SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;");
PQex
Jan Ehrhardt <[EMAIL PROTECTED]> writes:
> Architecture (example: Intel Pentium) : SGI Octane SI (MIPS R1)
> Operating System (example: Linux 2.0.26 ELF) :IRIX 6.4
> PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.1
> Compiler used (example: gcc 2.8.0) : MIPS PRO CC
"Andrew Brown" <[EMAIL PROTECTED]> writes:
> Using the attached test program to insert into a table with the following
> definition:
> expr_idint4 not null
> line_noint4 not null
> line_text varchar(254)
> The output is as follows:
> perl t2 x
> 2: ERROR: Unterminated qu
Bruce Momjian <[EMAIL PROTECTED]> writes:
|> The Makefile.shlib changes will have to be discussed with other Linux
|> developers so we are sure it will work on all platforms.
The problem with the current settings is that the linker is called
directly. This is wrong, it should always be called t
Here is an obscure bug I encountered.
Note, this was running on:
RedHat 6.2 (standard)
DBD-Pg-0.93
postgresql-7.0.2
All built using gcc 2.95.2
Using the attached test program to insert into a table with the following
definition:
expr_idint4 not null
line_noint4 not null
POSTGRESQL BUG REPORT TEMPLATE
Your name : Jan Ehrhardt
Your email address : [EMAIL PROTECTED]
System Configurati
"Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> What I can do is create a fake dataset, find some values that cause the problem,
>then give
> that to you. Would that be acceptable?
Sure, if you can do that. I just want to reproduce the crash here.
regards, tom l
On Thu, Jul 06, 2000 at 03:10:28AM -0400, Tom Lane wrote:
> "Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> >> I don't think I believe that backtrace. Could you send me the dump
> >> file?
>
> > The core file is never written to disk (I did verify that the environment I am
>running
> > p
"Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
>> I don't think I believe that backtrace. Could you send me the dump
>> file?
> The core file is never written to disk (I did verify that the environment I am
>running
> postgres under was setup to allow core files).
I don't want the corefi
On Thu, Jul 06, 2000 at 12:48:53AM -0400, Tom Lane wrote:
> "Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> > I have been able to make the backend crash using psql. I also took a dump
> > of the database while I had some known values that would trigger the problem.
> > Because of this, I c
14 matches
Mail list logo
