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
|
| Список | 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
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello
>> Github: http://github.com/fabriziomello
В списке pgsql-hackers по дате отправления: