Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
От | Dean Rasheed |
---|---|
Тема | Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist |
Дата | |
Msg-id | CAEZATCUDDXc9eAAjXO0Kd6o_y1B9JxEZqtzy6USgTKMWeSqh6w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop
tables that don't exist
|
Список | pgsql-hackers |
On 2 December 2013 19:37, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Dean Rasheed escribió: > >> +/* >> + * If a schema was explicitly specified, test if it exists. If it does not, >> + * report the schema as missing rather than the child object. >> + */ >> +static bool >> +schema_does_not_exist_skipping(List *objname, >> + const char **msg, >> + char **name) >> +{ >> + RangeVar *rel; >> + >> + rel = makeRangeVarFromNameList(objname); >> + >> + if (rel->schemaname != NULL && >> + !OidIsValid(LookupNamespaceNoError(rel->schemaname))) >> + { >> + *msg = gettext_noop("schema \"%s\" does not exist, skipping"); >> + *name = rel->schemaname; >> + >> + return true; >> + } >> + >> + return false; >> +} > > In success cases, are we leaking a lot of memory? In the error case I > guess it doesn't matter that the RangeVar is getting leaked (we're > aborting anyway), but if we're called and everything turns out to work, > are things cleaned up timely? > I think that memory gets freed at the end of the DROP command, so I don't think this is a concern. In any case, that RangeVar is only of order 50 bytes. If we were concerned about memory leakage here, a bigger concern would be the calling code in does_not_exist_skipping(), which is using NameListToString() which allocates at least 1024 bytes for the name of the non-existent object without freeing it. Regards, Dean
В списке pgsql-hackers по дате отправления: