Обсуждение: Port Bug Report: Problem concerns copy command with big oids
============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================
Your name : Helmar Spangenberg
Your email address : hspangenberg@frey.de
Category : runtime: back-end
Severity : serious
Summary: Problem concerns copy command with big oids
System Configuration
--------------------
Operating System : Linux 2.0.36
PostgreSQL version : 6.4
Compiler used : egcs 1.1.1
Hardware:
---------
Dual Pentium, 384M RAM
uname -a:
Linux godzilla 2.0.36 #8 Thu Jan 21 16:10:41 MET 1999 i686 unknown
Versions of other tools:
------------------------
We used postgresql of the SuSE 6.0 dist.
flex 2.5.4
GNU Make version 3.76.1
--------------------------------------------------------------------------
Problem Description:
--------------------
Using the SQL-command "COPY ... FROM" leads to the death of
the backend when the oid-counter steps over the 2 billion
frontier. As far as we could test, the other commands worked
fine.
--------------------------------------------------------------------------
Test Case:
----------
In our installation all 3 hours app. 4000000 datasets are
cleared and reinstalled using the copy command. After the
oids got bigger than 2147483647 the backend died during the
copy command. After a fresh installation of Postgres (oids
now starting again at 0) everything worked fine again.
Not a fix, but maybe a hint:
It seems to me that the internal representation of the oids
is not consistent (long int - unsigned long int). I
realized that the oid of ONE dataset sometimes was printed
as a negative number and in other cases as a positive
number (when big enough).
--------------------------------------------------------------------------
Solution:
---------
--------------------------------------------------------------------------
> Date: Sun, 14 Mar 1999 13:58:01 -0500 (EST) > From: Unprivileged user <nobody@hub.org> > To: pgsql-ports@postgreSQL.org > Not a fix, but maybe a hint: > It seems to me that the internal representation of the oids > is not consistent (long int - unsigned long int). I > realized that the oid of ONE dataset sometimes was printed > as a negative number and in other cases as a positive > number (when big enough). I guess that psql does not "recycle" oid numbers when you delete 1 oid and create a oid (BLOB) again. Another problem is that PSQL should delete the oid file when you delete the row that references it. --- _ _ _(_)(_)_ David Wetzel, Turbocat's Development, (_) __ (_) Buchhorster Strasse, D-16567 Muehlenbeck/Berlin, FRG, _/ \_ Fax +49 33056 82835 NeXTmail dave@turbocat.de (______) http://www.turbocat.de/ DEVELOPMENT * CONSULTING * ADMINISTRATION WATCH OUT FOR TURBOFAX for OPENSTEP!
This has been added to the TODO list. > Problem Description: > -------------------- > Using the SQL-command "COPY ... FROM" leads to the death of > the backend when the oid-counter steps over the 2 billion > frontier. As far as we could test, the other commands worked > fine. > > -------------------------------------------------------------------------- > > Test Case: > ---------- > In our installation all 3 hours app. 4000000 datasets are > cleared and reinstalled using the copy command. After the > oids got bigger than 2147483647 the backend died during the > copy command. After a fresh installation of Postgres (oids > now starting again at 0) everything worked fine again. > > Not a fix, but maybe a hint: > It seems to me that the internal representation of the oids > is not consistent (long int - unsigned long int). I > realized that the oid of ONE dataset sometimes was printed > as a negative number and in other cases as a positive > number (when big enough). > > -------------------------------------------------------------------------- > > Solution: > --------- > > > -------------------------------------------------------------------------- > > > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026