OID's

#31

Just to clarify, there is a difference between OIDs and XIDs. Object
IDs (OID) are a system assigned field to every row that eventually
wraps around. If you don't use them in your application you'll hever
really have a problem. The only exception is that statements that
modify structures in the database (CREATE TRIGGER/TABLE/INDEX/etc) may
fail if you're unlucky enough to try them and it happens to be exactly
the OID of an existing thing of that type.

Most people don't create 4 billion rows in their database so it's not
an issue. People who do are recommended to create their high churn
tables WITHOUT OIDS so they don't get used as fast. As an added bonus,
in recent versions you can actually save diskspace by not having them.

Transaction IDs (XID) are a different story, they track transactions
and what is visible and what isn't. Transaction wraparound means that
rows will disappear when their transaction ID (which was considered in
the past) is now in the future. Since 7.2 this problem is avoided by
doing a database wide VACUUM (not necessarily FULL) at least once every
billion transactions. This is not an onerous requirement so people
don't run into this anymore.

Before 7.2 you'd simply find your data missing one morning as the only
way to reset the XID was with an initdb. If you're still running a busy
database on something older than that, you *really* need to consider
taking appropriate measures! 7.2 is already fairly old now and all of
the major database destroying issues from then are now fixed.

Hope this helps,

On Tue, Nov 16, 2004 at 01:06:57PM +0200, Kostis Mentzelos wrote:

Quote:

I have read about oid wraparound in many messages but I don't understand
when it happens and when it is dangerus for my tables.

It affects developers that uses OIDS in their queryies?
What about database and tables (not total or total) disappearences?

Kostis.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

--
Martijn van Oosterhout <kleptog (AT) svana (DOT) org> http://svana.org/kleptog/

Quote:

Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
tool for doing 5% of the work and then sitting around waiting for someone
else to do the other 95% so you can sue them.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFBmzreY5Twig3Ge+YRAnE8AKCtPCzFwHDkg/U3E9DFCRC9+tJ91gCgvXZq
G4HrNDbv6p/YVv6maUrXH74=
=JHt/
-----END PGP SIGNATURE-----

#32

Helps me. Thanks for the clairification.

On Wednesday 17 November 2004 06:49 am, Martijn van Oosterhout saith:

Quote:

Just to clarify, there is a difference between OIDs and XIDs. Object
IDs (OID) are a system assigned field to every row that eventually
wraps around. If you don't use them in your application you'll hever
really have a problem. The only exception is that statements that
modify structures in the database (CREATE TRIGGER/TABLE/INDEX/etc) may
fail if you're unlucky enough to try them and it happens to be exactly
the OID of an existing thing of that type.

Most people don't create 4 billion rows in their database so it's not
an issue. People who do are recommended to create their high churn
tables WITHOUT OIDS so they don't get used as fast. As an added bonus,
in recent versions you can actually save diskspace by not having them.

Transaction IDs (XID) are a different story, they track transactions
and what is visible and what isn't. Transaction wraparound means that
rows will disappear when their transaction ID (which was considered in
the past) is now in the future. Since 7.2 this problem is avoided by
doing a database wide VACUUM (not necessarily FULL) at least once every
billion transactions. This is not an onerous requirement so people
don't run into this anymore.

Before 7.2 you'd simply find your data missing one morning as the only
way to reset the XID was with an initdb. If you're still running a busy
database on something older than that, you *really* need to consider
taking appropriate measures! 7.2 is already fairly old now and all of
the major database destroying issues from then are now fixed.

Hope this helps,

On Tue, Nov 16, 2004 at 01:06:57PM +0200, Kostis Mentzelos wrote:
I have read about oid wraparound in many messages but I don't understand
when it happens and when it is dangerus for my tables.

It affects developers that uses OIDS in their queryies?
What about database and tables (not total or total) disappearences?

Kostis.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if
your joining column's datatypes do not match

--
Quote: 28
"Without question, we need to disarm Saddam Hussein. He is a brutal,
murderous dictator, leading an oppressive regime . . . He presents a
particularly grievous threat because he is so consistently prone to
miscalculation. . . . And now he is miscalculating America's response
to his continued deceit and his consistent grasp for weapons of mass
destruction. . . . So the threat of Saddam Hussein with weapons of mass
destruction is real. . . ."

-- Sen. John F. Kerry (D, MA), Jan. 23. 2003

Work: 1-336-372-6812
Cell: 1-336-363-4719
email: terry (AT) esc1 (DOT) com

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

#33

On 11/16/2004 4:52 AM, Michael Glaesemann wrote:

Quote:

On Nov 16, 2004, at 6:42 PM, Peter Eisentraut wrote:

Am Dienstag, 16. November 2004 10:01 schrieb Joolz:
Michael Glaesemann zei:
OIDS are a system level implementation. They are no longer required
(you can make tables without OIDS) and they may go away someday.

Out of curiosiry: how will we handle blobs once the OID's are gone?

They won't go away. This is one reason.

Peter,

You sound pretty certain. I can imagine there might be a way to handle
BLOBs without OIDs. I'm not saying that I know what it is, but I
recognize the possibility.

A sequence and converting the blob identifier to int8 would be one ...

Jan

--
#================================================= =====================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================= = JanWieck (AT) Yahoo (DOT) com #

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

#34

On 11/16/2004 6:32 AM, Holger Klawitter wrote:

Quote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A little bit OT, but:
is there a way of removing duplicate rows in a table without OIDs?

There is still the CTID.

Jan

Quote:

Mit freundlichem Gruß / With kind regards
Holger Klawitter
- --
lists <at> klawitter <dot> de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFBmeVA1Xdt0HKSwgYRAklNAJ4l0KtMVF2Tkhx5ZgyPR3 8LHXd/LACeNk4q
mwf/f5rI7VdckPfgfUotnSc=
=qpV0
-----END PGP SIGNATURE-----

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

--
#================================================= =====================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================= = JanWieck (AT) Yahoo (DOT) com #

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

OID's

comp.databases.postgresql.general comp.databases.postgresql.general

Re: OID's - 11-17-2004 , 05:49 AM

Re: OID's - 11-17-2004 , 06:07 AM

Re: OID's - 11-18-2004 , 08:18 PM

Re: OID's - 11-18-2004 , 08:21 PM