Bug: Inserting
If PostgreSQL failed to compile on your computer or you found a bug that
is likely to be specific to one platform then please fill out this form
and e-mail it to pgsql-ports@postgresql.org.
To report any other bug, fill out the form below and e-mail it to
pgsql-bugs@postgresql.org.
If you not only found the problem but solved it and generated a patch
then e-mail it to pgsql-patches@postgresql.org instead. Please use the
command "diff -c" to generate the patch.
You may also enter a bug report at http://www.postgresql.org/ instead of
e-mail-ing this form.
============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================
Your name : Kimmo Lahdensivu
Your email address : kimmol@tulppaani.com
System Configuration
---------------------
Architecture (example: Intel Pentium) : Intel Pentium Xeon III 500MHz x2 SMP
Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.13 ELF
PostgreSQL version (example: PostgreSQL-6.5.2): PostgreSQL-6.5.3
Compiler used (example: gcc 2.8.0) : gcc 2.7.2.3
Please enter a FULL description of your problem:
------------------------------------------------
The problem is that in some situations postgresql doesn't store the data it
receives. So, for example, if I make a normal INSERT statement the row supposed
to appear in the database isn't there. This has happened only in situation
where there are at least 20 tables in the database. The database files are
not corrupted. I made a dump of the database and moved the database to
another system with clean postgresql installation and the same happened
trying to insert to the table.
There was one common thing to all the situations I was unable to insert.
They were made using postgresql library of php3 (3.0.9). There were no
error messages or anything but the data just didn't appear in the db.
I solved this problem quick & dirty way by executing psql from the php
script with the statement as a parameter of it. It worked well but now
I have one table that it doesn't work with. The effect is the same as
with php. Everything seems to be fine but the data isn't there.
I run postmaster in debug mode in one console to see if there was something
worth seeing. The output of the debug was exactly the same in cases where
the data disappeared and when it got stored in the db. No error messages.
The problem has been at least in versions 6.3, 6.4 & 6.5.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------
If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------
kimmol@duniversum.com (Kimmo Lahdensivu) writes:
There was one common thing to all the situations I was unable to insert.
They were made using postgresql library of php3 (3.0.9). There were no
error messages or anything but the data just didn't appear in the db.
I think PHP is one of the interfaces that has "autocommit" control (a
seriously misnamed feature IMHO). What this really means is that your
changes *don't* get committed until you say so, because the interface
library issues a BEGIN WORK behind-your-back. If you disconnect without
having done the correct incantation to cause a COMMIT, presto: all your
work is rolled back.
I don't know PHP well enough to know the magic incantation, however...
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofFri17Dec1999081811+0200m11yqiR-007yQMC@duniversum.com | Resolved by subject fallback
kimmol@duniversum.com (Kimmo Lahdensivu) writes:
There was one common thing to all the situations I was unable to insert.
They were made using postgresql library of php3 (3.0.9). There were no
error messages or anything but the data just didn't appear in the db.I think PHP is one of the interfaces that has "autocommit" control (a
seriously misnamed feature IMHO). What this really means is that your
changes *don't* get committed until you say so, because the interface
library issues a BEGIN WORK behind-your-back. If you disconnect without
having done the correct incantation to cause a COMMIT, presto: all your
work is rolled back.I don't know PHP well enough to know the magic incantation, however...
No. This is not the problem. At the current situation I'm not able to
insert a row into the table. It fails constantly without any error
messages and even if I call "psql -c "Insert statement" dbase" from
the php script without using the php interface. This is not a problem
appearing sometimes but all the time after it has first happened.
'' Kimmo
From bouncefilter Fri Dec 17 23:53:19 1999
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA46412
for <hackers@postgreSQL.org>; Fri, 17 Dec 1999 23:53:00 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id RAA11857;
Fri, 17 Dec 1999 17:21:57 GMT
Sender: lockhart@hub.org
Message-ID: <385A7135.51ECBBA2@alumni.caltech.edu>
Date: Fri, 17 Dec 1999 17:21:57 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Edwin Ramirez <ramirez@doc.mssm.edu>
CC: Bruce Momjian <pgman@candle.pha.pa.us>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Oracle Compatibility (Translate function)
References: <199912160129.UAA11666@candle.pha.pa.us>
<3858F60E.312E3BA3@doc.mssm.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I have modified the translate function in order to improve its
compatibility with Oracle. It now supports the replacement of
multiple characters and it will also shorten the length of the string
when characters are replaced with nothing.
[Note: The arguments are different from the original translate]
Can this function replace the existing function in the distribution?
afaik yes. Does anyone have a problem with this (it allows
substitution of multiple characters)? I think the system tables will
need to be updated; I'll do this within the next week or so if noone
else has already taken this on.
btw, there is some chance that when we go to native support for
NATIONAL CHARACTER etc then TRANSLATE() will need to become SQL92
compliant (and basically a different function). But that is an issue
for later, and we may be able to solve it without having to give up on
the Oracle version.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California