Re: Error during restore - dump taken with pg_dumpall -c option
От | Michael Paquier |
---|---|
Тема | Re: Error during restore - dump taken with pg_dumpall -c option |
Дата | |
Msg-id | CAB7nPqQpWRtOQ1i7EBy89V2ZGWT+ATaybFft-UpnBwYaOcnqaA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Error during restore - dump taken with pg_dumpall -c option (Fabrízio de Royes Mello <fabriziomello@gmail.com>) |
Список | pgsql-hackers |
On Thu, May 12, 2016 at 9:48 PM, Fabrízio de Royes Mello <fabriziomello@gmail.com> wrote: > > > 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? The patch looks correct to me: as far as I recall we give no guarantee that a dump generated by pg_dump based on a given version would load data correctly in an older version of the backend. So, when with 9.6's pg_dump, dumping from a < 9.6 backend, bypassing the role names beginning by "pg_" and letting the user know about their existence without dumping them looks fine. -- Michael
В списке pgsql-hackers по дате отправления: