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:
+----+--------+--------+------+
|xmin|attrelid|attname |attnum|
+----+--------+--------+------+
|1 |1262 |tableoid|-6 |
|1 |1262 |cmax |-5 |
|1 |1262 |xmax |-4 |
|1 |1262 |cmin |-3 |
|1 |1262 |xmin |-2 |
|1 |1262 |ctid |-1 |
|1 |1262 |oid |1 |
|1 |1262 |datname |2 |
...
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
PS: I'm not familiar with mailing lists. Is it ok to attach images here?
On Thu, Sep 2, 2021 at 1:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Laurenz Albe <laurenz.albe@cybertec.at> writes:
> > On Thu, 2021-09-02 at 08:50 +0300, Alexander Kass wrote:
> >> We have a small number of users that do not have xmin in pg_database
> >> (we've asked them to try `select xmin from pg_database` and got
> >> `column xmin does not exist`).
>
> > All PostgreSQL tables have "xmin", and all catalog tables do as well.
>
> Indeed. This seems to be evidence of corruption in the pg_attribute
> catalog. If you're really lucky, reindexing pg_attribute might fix
> it, though I wonder what other problems there are. (It's odd though
> that identical corruption would happen to different installations.)
>
> regards, tom lane