Re: No xmin in pg_database

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexander Kass <alexander(dot)kass(at)jetbrains(dot)com>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: No xmin in pg_database
Date: 2021-09-08 13:45:36
Message-ID: 3262238.1631108736@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alexander Kass <alexander(dot)kass(at)jetbrains(dot)com> writes:
> I've asked the user to perform `SELECT xmin, * from pg_attribute WHERE
> attrelid = 'pg_catalog.pg_database'::regclass` to check the
> attributes.
> The user has sent me that a couple of times: both times xmin is
> different, attrelid is different, both have a big value.
> Does that mean that pg_database is recreated?
> Also system attributes are different. My result looks like:
> ...
> His result (apart from dat* attributes) contains only tableoid and
> oid. Also his attnum numeration starts from tableoid = 1, oid = 2,
> datname = 3
> I'm puzzled

It's pretty hard to read these details and not conclude that somebody
has been manually manipulating that catalog. Missing rows might possibly
be explained by index corruption ... but there is no scenario under which
pg_database could have an OID different from 1262, nor could this change
of attnums for the surviving rows ever have happened via Postgres-internal
processes.

I'm about ready to file this under "you broke it, you get to keep both
pieces".

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Miles Elam 2021-09-08 14:55:04 Logical Replication to Older Version
Previous Message Alexander Kass 2021-09-08 13:20:44 Re: No xmin in pg_database