Re: Damaged (during upgrade?) table, how to repair?
От | W.P. |
---|---|
Тема | Re: Damaged (during upgrade?) table, how to repair? |
Дата | |
Msg-id | ab8f3885-ef7c-0495-42b6-6940f3ef0375@wp.pl обсуждение исходный текст |
Ответ на | Re: Damaged (during upgrade?) table, how to repair? (Adrian Klaver <adrian.klaver@aklaver.com>) |
Ответы |
Re: Damaged (during upgrade?) table, how to repair?
|
Список | pgsql-general |
W dniu 04.07.2021 o 19:48, Adrian Klaver pisze: > On 7/4/21 9:33 AM, W.P. wrote: >> W dniu 02.07.2021 o 21:05, Adrian Klaver pisze: >>> On 7/2/21 10:18 AM, W.P. wrote: >>>> W dniu 02.07.2021 o 17:16, Adrian Klaver pisze: >>> >>>>> >>>>> So you have backup of the failed machine's disk stored somewhere >>>>> else? >>>> >>>> >>>> No, I have disc from this machine, looks not damaged (random >>>> files). Only problem that OS does not boot beyond "emergency mode". >>> >>> I would say your second sentence contradicts your first. >> >> Nope ;). There was 1 500GB disc, with Fedora24 and Postgres 9.5. Then >> copied "sector by sector" (and resized partitions, volumes, fs) to >> 1TB one. This was my "working" disc. >> > > Just dawned on me, why aren't you working directly from the 1TB disk? > > It has the presumably intact files from before the OS/Postgres > upgrades and the power experiment. > "Only problem that OS does not boot beyond "emergency mode"."... But I made some progress: - booted up into single user, bring up Ethernet, now CAN start Postgres but only using pg_ctl directly, does NOT work using systemctl... So problem is (possibly) with systemd. Dumped base, pg_dump worked fine, dump gzipped is < 600MB, so I assume that somehow Postgres recovered from my (stupid) move... BTW, pls respond only to list. Laurent
В списке pgsql-general по дате отправления: