Re: pg_dump error attempting to upgrade from PostgreSQL 10 to PostgreSQL 12
От | Thomas Munro |
---|---|
Тема | Re: pg_dump error attempting to upgrade from PostgreSQL 10 to PostgreSQL 12 |
Дата | |
Msg-id | CA+hUKGJThsDYg1VD8nOrV1o5FOrtCQisnim7p2neS1CJUWMnTw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_dump error attempting to upgrade from PostgreSQL 10 to PostgreSQL 12 (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: pg_dump error attempting to upgrade from PostgreSQL 10 to PostgreSQL 12
|
Список | pgsql-bugs |
On Sat, Nov 7, 2020 at 1:10 PM Tomas Vondra <tomas.vondra@enterprisedb.com> wrote: > On Thu, 5 Nov 2020 21:19:17 +0000 > "Burgess, Freddie" <Freddie.Burgess@maxar.com> wrote: > > BACKUP: pg_dump -U postgres -d <database> > sherlock.dmp <- From the > > pg10 instance RESTORE: psql -U postgres -d <database> -1 -f > > sherlock.dmp <- On the pg12 instance > > > > Postgres Log: > > > > free(): invalid pointer > > free(): invalid pointer > > 2020-11-05 14:07:33.784 EST [26] LOG: background worker "parallel > > worker" (PID 150) was terminated by signal 6: Aborted 2020-11-05 > It'd be interesting to know what is doing the crashing parallel worker. > Considering it's a background worker, the easiest way is probably > enabling core dumps and inspecting them with gdb. Make sure you have > debug symbols installed and send us the backtrace. I guess that would have to be a parallel index build. The OP could try setting max_parallel_mainentance_workers = 0 to see if that's a useful workaround, until we can track the problem (double free?) down and fix it, or maybe that would reveal that the same crash can also happen in a regular backend.
В списке pgsql-bugs по дате отправления: