Never seen a *negative* OID before. This is a first-class "crime scene"!

>     ... attrelid=-1519044407::oid ...
>     ... rel.oid = -1519044407::oid ...

#Facts

###0.

    2^32 - 1519044407 = 2775922889

And we have verified that OID `2775922889` indeed exists in your DB. Tests:

    SELECT * FROM pg_class WHERE oid = 2775922889;
    SELECT * FROM pg_class WHERE oid = '-1519044407';
    SELECT * FROM pg_class WHERE relname = 'test_table';

###1.
[The manual about object identifier types:][1]

> The `oid` type is currently implemented as an unsigned four-byte integer. 

###2.
Postgres cast accepts *signed* integer anyway (!)

The Postgres I/O conversion from string literals, as well as the cast from `integer`currently (pg 12) accepts negative integer values / literals as input anyway. Seems to just binary coerce a signed four-byte integer to *unsigned four-byte integer* and vice versa. Worth keeping in mind at least.

These, oddly, work:

    test=# SELECT '-1519044407'::oid, '-1519044407'::int::oid;
        oid     |    oid     
    ------------+------------
     2775922889 | 2775922889

Leads to different representation when casting to `int` versus `bigint`:

    test=# SELECT (oid '2775922889')::int
    test-#      , (oid '2775922889')::bigint;
        int4     |    int8    
    -------------+------------
     -1519044407 | 2775922889  -- !!

###3.
[The manual on *Numeric Constants*][2]:

> Note that any leading plus or minus sign is not actually considered part of the constant; it is an operator applied to the constant.

###4.
The cast operator `::` [takes precedence][3] over the unary minus operator (`-`).

# Conclusions

###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.**

*Improved with comments from Daniel Vérité:*

*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][4].) 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][5] for how OID collisions are dealt with after wraparound. Collisions incur a minor performance penalty.

*Or* somebody/something messed with your system catalogs.

###2.
**If the above query was generated by pgAdmin4, there is a serious bug**.

Maybe that did not surface, yet, as nobody had OIDs in that range in the system catalogs, yet?

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`.

But this does **not**:

    -1519044407::oid 

**Because:**

 - 1. `1519044407` is taken as numeric literal and initially coerced to `integer`.
 - 2. The cast operator `::` takes precedence over the sign operator `-` and the integer is cast to the (wrong!!) `oid`.
 - 3. Finally, Postgres tries to apply the sign operator and, luckily, fails with the reported error message:

 >     ERROR:  operator does not exist: - oid at character 125

 If it would not fail there, serious nonsense might occur.

*db<>fiddle [here](https://dbfiddle.uk/?rdbms=postgres_12&fiddle=33a1bbcc2b79e98fab5e8fda58ef39ea)*


  [1]: https://www.postgresql.org/docs/current/datatype-oid.html
  [2]: https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS-NUMERIC
  [3]: https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-PRECEDENCE-TABLE
  [4]: https://www.postgresql.org/docs/12/release-12.html
  [5]: https://git.postgresql.org/gitweb/?p=postgresql.git;f=src/backend/catalog/catalog.c;hb=HEAD#l298