Bartosz Nowak <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
