Oid: the Object ID of the row ). This field only appears when the with oids is used when the table is created, or when the default_with_oids configuration parameter is set. This field is of the oId type (with the same name as the field ).
Example:
CopyCode The Code is as follows: Create Table pg_language
(
Lanname name not null,
Lanowner OID not null,
Lanispl Boolean not null,
Lanpltrusted Boolean not null,
Lanplcallfoid OID not null,
Lanvalidator OID not null,
Lanacl aclitem []
)
With (
Oids = true
);
the oId is a 32-bit volume, which is assigned a value on a universal counter in the same cluster. For a large or long-time database, this counter may overlap. Therefore, it is very wrong to assume that the oId is unique unless you take measures to ensure that they are unique.
Xid: Transaction ID, which is also a 32-bit volume. In a database that has been running for a long time, it may overlap. Database errors may occur after overlap, so you need to take measures to solve the problem. As long as we take appropriate maintenance steps, this is not a terrible problem. For example, we define vaccum. Or manually reset.
run the following command to reset the transaction log:
$ pg_resetxlog -- help
the pg_resetxlog command resets the PostgreSQL transaction log.
usage:
pg_resetxlog [Option]... datadir
Option parameter:
-e xidepoch: sets the ID epoch of the next transaction.
-F implements force update.
-l TLI, file, SEG forces the minimum Wal start position of the new transaction log
-M Xid to set the next multi transaction id
-N is not updated, but the current control value is retrieved, command Used in the experiment
-o oid sets the next OID and resets the oId
-O offset sets the offset of the next multi transaction id
-x Xid sets the next transaction ID, after resetting the XId
, I am still confused about the internal issue. Haha !!