Return to Answer

I have posted a note to the pgadmin-hackers list.
A related bug has been logged before. I added a note there, too. (Access only with Postgres community account.)

I have posted a note to the pgadmin-hackers list.
A related bug has been logged before there, too. (Access with Postgres community account.) It was traced back to a psycopg2 issue using the wrong data type for OID in 32 bit versions. Should be fixed in psycopg2 version 2.8.4 (which pgAdmin4 depends upon).

Seems like it operates with the integer representation of OIDs, and naively pastes those as numeric literals including the sign by mistake in queries. A string literal would work: '-1519044407'::oid.

I have posted a note to the pgadmin-hackers list.

Seems like it operates with the integer representation of OIDs, and naively pastes those as numeric literals including the sign by mistake in queries. A string literal would work: '-1519044407'::oid. Or parentheses would make it work: (-1519044407)::oid.

I have posted a note to the pgadmin-hackers list.
A related bug has been logged before. I added a note there, too. (Access only with Postgres community account.)

###1. I have never seen OID numbers in that range in system catalogs before, and I have been working with all kinds of big databases. You have a problem in your DB.

Either you are burning OID numbers at an insane rate - already 2.8 billion numbers. ~ 1.5 billion remain until OID wraparound. Do you have any tables created with WITH OIDS? (Nobody should any more. The feature is deprecated and removed in Postgres 12.) Or some code excessively creating / dropping new objects? The OID counter is per instance, not per database, so all dbs contribute to OID consumption.
There is a comment in the source code for GetNewOidWithIndex for how OID collisions are dealt with after wraparound. Collisions incur a minor performance penalty.

db<>fiddle here

###1. I have never seen OID numbers in that range in system catalogs before, and I have been working with all kinds of big databases. You have a problem in your DB (cluster).

Either you are burning OID numbers at an insane rate - already 2.8 billion numbers. ~ 1.5 billion remain until OID wraparound. Do you have any tables created with WITH OIDS? (Nobody should any more. The feature is deprecated and removed in Postgres 12.) Or some code excessively creating / dropping new objects? The OID counter is per instance, not per database, so all dbs contribute to OID consumption.
There is a comment in the source code for GetNewOidWithIndex for how OID collisions are dealt with after wraparound. Collisions incur a minor performance penalty.

db<>fiddle here

I have posted a note to the pgadmin-hackers list.