From: | Moreno Andreo <moreno(dot)andreo(at)evolu-s(dot)it> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Pg11 -- MultiXactId xxxx has not been created yet -- apparent wraparound |
Date: | 2019-10-15 15:43:04 |
Message-ID: | 409a55a4-e380-e5e4-a1a4-d7e69b50ab98@evolu-s.it |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi Alvaro,
sorry for late reply, I've been out of office.
Il 09/10/19 19:51, Alvaro Herrera ha scritto:
> On 2019-Oct-07, Moreno Andreo wrote:
>
>> Unfortunately, it didn't work :(
>>
>> db0=# select * from failing_table where ctid='(3160,31)' for update;
>> ERROR: MultiXactId 12800 has not been created yet -- apparent wraparound
> Oh well. It was a long shot anyway ...
It was a long shot, but it was worth trying
>> Since the probability we are into corruption is very high, what if I \copy
>> all the table but the failing row(s) to an external file, drop and recreate
>> the table, and then \copy clean data back inside?
> Yes, that should work.
It did not work... I think there was some big deal with the cluster itself.
To extract these small parts of data I had to SELECT using OFFSET and LIMIT.
Well, the same query (i.e. select * from table offset 35 limit 145) run
as it is worked well, but from the moment I put it into a COPY
statement, it was messing again with multixact, even if I tried back the
only query.
It ended recovering data from backups (2 days old, and that's good news)
Thanks for your time
Moreno.-
>
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Lewis | 2019-10-15 15:58:47 | Re: SELECT returnig a constant |
Previous Message | Andrew Gierth | 2019-10-15 14:28:40 | Re: Inserting multiple rows wtih a SELECt in the values clause |