Re: Error during restore - dump taken with pg_dumpall -c option

Поиск
Список
Период
Сортировка
От Fabrízio de Royes Mello
Тема Re: Error during restore - dump taken with pg_dumpall -c option
Дата
Msg-id CAFcNs+pLqnijoga6fL6cJFEf4vPSPdRVuwTN1E-MQMj=Lt8Ruw@mail.gmail.com
обсуждение исходный текст
Ответ на Error during restore - dump taken with pg_dumpall -c option  (Rushabh Lathia <rushabh.lathia@gmail.com>)
Ответы Re: Error during restore - dump taken with pg_dumpall -c option  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers


Em quinta-feira, 12 de maio de 2016, Rushabh Lathia <rushabh.lathia@gmail.com> escreveu:

On master branch when we do pg_dumpall with -c option, I can see that
it also dumping the "DROP ROLE pg_signal_backend", which seems wrong.
Because when you restore the dump, its throwing an error
"ERROR:  cannot drop role pg_signal_backend because it is required by the database system".


dumpRoles()::pg_dumpall.c does have logic to not dump "CREATE ROLE"  if the
rolename starts with "pg_", but similar check is missing into dropRoles() function.

PFA patch, to fix the problem in the similar way its been handled into dumpRoles().


Shouldn't this logic be applied just to version >= 9.6? I ask it because you write a special query filtering rolname !~ '^pg_' and again check it using strcmp before the drop role output. Is this the expected behavior? 


--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ashutosh Sharma
Дата:
Сообщение: Re: Perf Benchmarking and regression.
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: Incremental refresh of materialized view - Patch