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