| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Leftover invalidation handling in RemoveRelations |
| Date: | 2017-03-15 18:40:44 |
| Message-ID: | 20170315184044.7bedzxktdcuujz5z@alap3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 entry since 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 since the
* start of our transaction: if we don't flush the old syscache entry,
* then we'll latch onto that entry and 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-03-15 18:46:22 | Re: Leftover invalidation handling in RemoveRelations |
| Previous Message | Robert Haas | 2017-03-15 18:31:41 | Re: Microvacuum support for Hash Index |