[HACKERS] Leftover invalidation handling in RemoveRelations
От | Andres Freund |
---|---|
Тема | [HACKERS] Leftover invalidation handling in RemoveRelations |
Дата | |
Msg-id | 20170315184044.7bedzxktdcuujz5z@alap3.anarazel.de обсуждение исходный текст |
Ответы |
Re: [HACKERS] Leftover invalidation handling in RemoveRelations
|
Список | pgsql-hackers |
Hi, reviewing some citus code copied from postgres I noticed that RemoveRelations() has the following bit: /* * These next few steps are a great deal like relation_openrv, but we * don't bother building a relcache entrysince we don't need it. * * Check for shared-cache-inval messages before trying to access the * relation. This is needed to cover the case where the name * identifies a rel that has been dropped and recreated sincethe * start of our transaction: if we don't flush the old syscache entry, * then we'll latch onto that entryand suffer an error later. */ AcceptInvalidationMessages(); /* Look up the appropriate relation using namespace search. */ state.relkind = relkind; state.heapOid = InvalidOid; state.concurrent = drop->concurrent; relOid = RangeVarGetRelidExtended(rel, lockmode, true, false, RangeVarCallbackForDropRelation, (void *) &state); which doesn't seem to make sense - RangeVarGetRelidExtended does invalidation handling on it's own. Looks like this was left there in the course of http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=2ad36c4e44c8b513f6155656e1b7a8d26715bb94 ISTM AcceptInvalidationMessages() and preceding comment should just be removed? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: