Обсуждение: 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