From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bartosz Nowak <grubby(at)go2(dot)pl> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: pg_dumpall problem - duplicated users |
Date: | 2005-09-01 19:11:28 |
Message-ID: | 5470.1125601888@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Bartosz Nowak <grubby(at)go2(dot)pl> writes:
> Tom Lane napisa(a):
>> You could manually delete either row, probably better to zap the second
>> one:
>> delete from pg_shadow where ctid = '(1,25)';
> Heh... i wish it was that easy - i tried it already :] When i delete the
> 'second' postgres user (with passwd set) PG is acting like there is no
> postgres account at all:
> ...
> And i cannot modify row of 'first' postgres user (without passwd set)
> with or without 'second' present:
> mw=> delete from pg_shadow where ctid = '(0,1)' ;
> DELETE 0
Ugh. That's looking more like you have a transaction ID wraparound
problem. How long has it been since pg_shadow was last vacuumed?
You could try a "VACUUM FREEZE pg_shadow" and see if the rows act any
more normally after that. (Better take a filesystem-level backup
first, so you can get out of it if that makes things worse.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | GRUbY | 2005-09-01 19:34:22 | Re: pg_dumpall problem - duplicated users |
Previous Message | GRUbY | 2005-09-01 19:08:54 | Re: pg_dumpall problem - duplicated users |