Lucas,
If you run out of OIDs you are doing something wrong. We haven't supported
user space OIDs in a lot of releases. Which release are you using?
JD
On Thu, Jun 9, 2022 at 2:11 AM Lucas wrote:
> Hello,
>
> In the company I work for, some clusters reached the OID limit (2^32) and
> we had to
relnamespace = n.oid
WHERE relkind IN ('r', 't', 'm')
AND n.nspname NOT IN ('pg_toast')
ORDER BY 2 DESC LIMIT 100;
From: Adrian Klaver
Sent: Thursday, June 9, 2022 3:02 PM
To: Lucas ; pgsql-general@lists.postgresql.org
On 6/9/22 02:10, Lucas wrote:
Hello,
In the company I work for, some clusters reached the OID limit (2^32)
and we had to reinstall the cluster.
Was this really about OIDs or XID wraparound?:
https://www.postgresql.org/docs/14/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND
I was wondering if
Lucas writes:
> In the company I work for, some clusters reached the OID limit (2^32) and
> we had to reinstall the cluster.
Uh ... why did you think you needed to do that? The OID counter
will wrap around and things should carry on fine. There are defenses
to prevent creation of duplicate OID
Hello,
In the company I work for, some clusters reached the OID limit (2^32) and
we had to reinstall the cluster.
I was wondering if there is any discussion on:
* "compress" the OID space
* "warp around" the OID space
* segment a OID range for temporary tables with "wrap around"
--
Lucas
