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@xxxxxxxxxxxxx> wrote: > > Laurenz Albe <laurenz.albe@xxxxxxxxxxx> 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
