From: | "W(dot)P(dot)" <laurentp(at)wp(dot)pl> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Problem with PG 11 database on OrangePi3 (ARMBIAN, ARM64) after disk disrupion (problem with USB disk connection) |
Date: | 2022-04-08 17:18:37 |
Message-ID: | 0b607694-8fb2-7250-4188-67672c787cd6@wp.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> If it is experimental you could try pg_resetwal:
>>
>> https://www.postgresql.org/docs/11/app-pgresetwal.html
>>
>
> Found this, had to use -f (program hint), but no luck. Same error.
>
> Is there anything else?
>
Problem stille here: during restore (from pg_dumpall on 11 on i386)
server on OPi crashed during CREATE INDEX phase. Some indexes and
triggers are missing.
SQL file has 16GB...
How can I prevent this in future (1), and (2) how to repair (maybe doing
dump/restore again?) the "slave" database?
I'd like to have a replica of my DB on laptop, especially after seeing
unrecoverable crash on OPi...
Laurent
> [BTW my "logical restore" runs already 9h... still making indexes, DB
> is not very large, on i386 ~50GB]
>
>
> Laurent
>
>
>> Read all the way through for the ifs/ands/buts.
>>
>>> If it is not possible to get rid ("somehow") of this "replication
>>> error", I will do a "logic restore" -> I have similar database on my
>>> laptop, so I'll get a pg_dumpall from this one, then recreate fresh
>>> DB on OPi and restore from SQL.
>>>
>>>
>>> It looks that DATA in PG DB is protected by various mechanisms very
>>> well, but "dictionary data" (in this case replication data) is not
>>> (as much). And in my case ext4 recovery mechanisms failed.
>>>
>>> This makes me logical replication more appealing.
>>>
>>>
>>> Laurent
>>>
>>>
>>>
>>
>>
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2022-04-08 17:56:25 | FOR integer loop bug? |
Previous Message | Rob Sargent | 2022-04-08 17:05:08 | Re: Long running processes and commit writing to disk |