Postgres Pro
Downloads
Home   >   mailing lists

Thread: Port Bug Report: Problem concerns copy command with big oids

Port Bug Report: Problem concerns copy command with big oids

From
Unprivileged user
Date:
============================================================================
                        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:
---------


--------------------------------------------------------------------------

Re: [PORTS] Port Bug Report: Problem concerns copy command with big oids

From
David Wetzel
Date:
> 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!

Re: [PORTS] Port Bug Report: Problem concerns copy command with big oids

From
Bruce Momjian
Date:
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