Bartosz Nowak <grubby@xxxxxx> writes: > postgres=> select ctid,xmin,xmax,cmin,xmax,* from pg_shadow where > usename = 'postgres'; > ctid | xmin | xmax | cmin | xmax | usename | usesysid | > usecreatedb | usesuper | usecatupd | passwd > | valuntil | useconfig > --------+------------+-------+-------+-------+----------+----------+-------------+----------+-----------+-------------------------------------+----------+----------- > (0,1) | 1 | 50469 | 50469 | 50469 | postgres | 1 | > t | t | t | > | | > (1,25) | 2559800612 | 0 | 0 | 0 | postgres | 1 | > t | t | t | md5c084502ed11efa9d3d96d29717a5e555 > | | > (2 rows) Hmm --- clearly, that second xmin is corrupt. I'd venture that this is the result of a rolled-back (crashed?) ALTER USER SET PASSWORD operation, in which somehow the new tuple's xmin got clobbered ... and more than likely, its XMIN_COMMITTED bit got set at the same time. You could manually delete either row, probably better to zap the second one: delete from pg_shadow where ctid = '(1,25)'; and then things should be OK. A dump and reload wouldn't be a bad idea though, since there may be other corruption elsewhere that you haven't noticed yet. regards, tom lane
