| From: | Arjen Nienhuis <a(dot)g(dot)nienhuis(at)gmail(dot)com> |
|---|---|
| To: | shutyaev(at)gmail(dot)com |
| Cc: | daniel(at)manitou-mail(dot)org, andres(at)anarazel(dot)de, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: pg_upgrade and wraparound |
| Date: | 2018-06-26 07:57:30 |
| Message-ID: | CAG6W84JMfRxRkVJQkok79tH-jgLYhO_jXChg3svxOiVbpX1Hvw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, Jun 26, 2018 at 8:38 AM Alexander Shutyaev <shutyaev(at)gmail(dot)com> wrote:
>
> Hello again,
>
> I've performed another test - I've migrated to the new cluster using dump restore: pg_dumpall | psql. It went well, although it took 6 days while pg_upgrade usually took a night.
>
> Is there any hope the issue with pg_upgrade can be resolved? If not, could you give me some hints as to how can I decrease time needed for pg_dumpall | psql?
If you use pg_dump with the custom format you can use pg_restore
--jobs=n to do a parallel restore.
I think you can do pg_dumpall --globals-only to restore users, and
then do a pg_dump per database.
Groeten, Arjen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Emanuele Musella | 2018-06-26 08:05:41 | Problem Postgres |
| Previous Message | Alexander Shutyaev | 2018-06-26 06:38:22 | Re: pg_upgrade and wraparound |