From: | Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com> |
---|---|
To: | Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Error during restore - dump taken with pg_dumpall -c option |
Date: | 2016-05-12 12:48:58 |
Message-ID: | CAFcNs+pLqnijoga6fL6cJFEf4vPSPdRVuwTN1E-MQMj=Lt8Ruw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Em quinta-feira, 12 de maio de 2016, Rushabh Lathia <
rushabh(dot)lathia(at)gmail(dot)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
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello
>> Github: http://github.com/fabriziomello
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2016-05-12 14:25:57 | Re: Incremental refresh of materialized view - Patch |
Previous Message | Ashutosh Sharma | 2016-05-12 12:39:07 | Re: Perf Benchmarking and regression. |