[HACKERS] Leftover invalidation handling in RemoveRelations - Mailing list pgsql-hackers

From Andres Freund
Subject [HACKERS] Leftover invalidation handling in RemoveRelations
Date
Msg-id 20170315184044.7bedzxktdcuujz5z@alap3.anarazel.de
Whole thread Raw
Responses Re: [HACKERS] Leftover invalidation handling in RemoveRelations  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Microvacuum support for Hash Index
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Leftover invalidation handling in RemoveRelations