gist microvacuum doesn't appear to care about hot standby?

Hi,

Am I missing something or did

commit 013ebc0a7b7ea9c1b1ab7a3d4dd75ea121ea8ba7
Author: Teodor Sigaev <teodor@sigaev.ru>
Date:   2015-09-09 18:43:37 +0300

    Microvacuum for GIST

    Mark index tuple as dead if it's pointed by kill_prior_tuple during
    ordinary (search) scan and remove it during insert process if there is no
    enough space for new tuple to insert. This improves select performance
    because index will not return tuple marked as dead and improves insert
    performance because it reduces number of page split.

    Anastasia Lubennikova <a.lubennikova@postgrespro.ru> with
     minor editorialization by me

entirely disregard recovery conflict handling?  The index entries it
removes could very well be visible to a snapshot on the standby. That's
why the equivalent nbtree (and hash) code does:


	/*
	 * If we have any conflict processing to do, it must happen before we
	 * update the page.
	 *
	 * Btree delete records can conflict with standby queries.  You might
	 * think that vacuum records would conflict as well, but we've handled
	 * that already.  XLOG_HEAP2_CLEANUP_INFO records provide the highest xid
	 * cleaned by the vacuum of the heap and so we can resolve any conflicts
	 * just once when that arrives.  After that we know that no conflicts
	 * exist from individual btree vacuum records on that index.
	 */
	if (InHotStandby)
	{
		TransactionId latestRemovedXid = btree_xlog_delete_get_latestRemovedXid(record);
		RelFileNode rnode;

		XLogRecGetBlockTag(record, 0, &rnode, NULL, NULL);

		ResolveRecoveryConflictWithSnapshot(latestRemovedXid,
											xlrec->onCatalogTable, rnode);
	}

Is there any reason something like that isn't necessary for gist? If so,
where's that documented? If not, uh, isn't that a somewhat serious bug
in gist?

Greetings,

Andres Freund