Dmitry Riachtchentsev ([EMAIL PROTECTED]) reports a bug with a severity of 1
The lower the number the more severe it is.
Short Description
server corrupt
Long Description
The follow short sequence of SQL requests leads to server corrupt:
1. Run psql and type:
begin;
CREATE SEQUENCE B;
commit;
\q
Sun OS 5.6
/bin/sh is a Bourne shell.
I changed the environment to use /bin/csh , then /bin/ksh & got the same
results.
Regards,
Ralph Lecessi
[EMAIL PROTECTED]
> --
> From: Tom Lane[SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, May 21, 2002 10:31 AM
> To: [EMAIL PROTECTED]
>Do you have another flavor of awk available to try? I still doubt
that
>it's gawk's fault, but we need to eliminate possibilities.
I ran with nawk (/usr/bin/nawk) & the parse error went away. Is their any
way I can check if the
awk output is valid (is their anything I can check
Gawk --version returns :
GNU awk 3.0.2
Thanks for the help . I'll try initdb as soon as I'm done building.
Regards,
Ralph Lecessi
> --
> From: Tom Lane[SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, May 21, 2002 12:57 PM
> To: Lecessi, Ralph
> Cc: [EMAIL PROTECTED]
> Subj
Tom L,
Thanks for answering my pushy opinions!
> Not actually true (probably due to a cut and paste error in your test
> suite). Your example specified '2001-07-31 10:00:00 PST' which is
> actually within the PDT time of year. PostgreSQL took you at your
> word
> on this one and evaluated the ti
[EMAIL PROTECTED] writes:
> The follow short sequence of SQL requests leads to server corrupt:
Looks like a bug to me too. I can still replicate the "NOTICE:
LockRelease: no such lock" in current sources, but it seems that
someone's already fixed the core dump; CVS tip does not crash.
Will look
Simon Kirby ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
timestamp() converts timezone in wrong direction
Long Description
timestamp() and extracting epoch from dates is totally broken:
[EMAIL PROTECTED] writes:
> Is there a patch that fixs this problem?
> If there is no patch, what is the root of the problem? Is there a kit of rules to
>avoid this situation?
After more detailed investigation, I find both the notice and the
subsequent crash have the same cause: after nextval(),
Richard Wooding ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Postgresql under cygwin leaking handles
Long Description
Hi,
I am running the following postgresql version:
"PostgreSQL 7.2.1 on i686-pc-cygwin, compiled by GCC 2
Ahoy there,
I'm the database admin of the Chemnitz Student's Network. Today we
noticed a bug in pg_dump that makes it impossible for us to use it to
create valid backups of our database. We're currently running pgsql
7.1.3, but I was able to reproduce the bug with the latest version,
7.1.2.
We've
Ingo van Lil <[EMAIL PROTECTED]> writes:
> We've got a table that inherits another one, and we had to add a new
> column to the mother table (and thus to the son, too). Now, if we dump
> the database, the columns of the INSERT resp. COPY commands for the data
> of the son table are in wrong order.
11 matches
Mail list logo
