Re: Error during restore - dump taken with pg_dumpall -c option - Mailing list pgsql-hackers

From Fabrízio de Royes Mello
Subject Re: Error during restore - dump taken with pg_dumpall -c option
Date
Msg-id CAFcNs+pLqnijoga6fL6cJFEf4vPSPdRVuwTN1E-MQMj=Lt8Ruw@mail.gmail.com
Whole thread Raw
In response to Error during restore - dump taken with pg_dumpall -c option  (Rushabh Lathia <rushabh.lathia@gmail.com>)
Responses Re: Error during restore - dump taken with pg_dumpall -c option  (Michael Paquier <michael.paquier@gmail.com>)
List 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 by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: Perf Benchmarking and regression.
Next
From: Kevin Grittner
Date:
Subject: Re: Incremental refresh of materialized view - Patch