Horton

Re: Extending SMgrRelation lifetimes

Heikki Linnakangas <hlinnaka@iki.fi>

View thread View on postgr.es
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Robert Haas <robertmhaas@gmail.com>, Thomas Munro <thomas.munro@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-12-08T07:20:26Z
Lists: pgsql-hackers 
On 29/11/2023 14:41, Heikki Linnakangas wrote:
> 2. A funny case with foreign tables: ANALYZE on a foreign table calls
> visibilitymap_count(). A foreign table has no visibility map so it
> returns 0, but before doing so it calls RelationGetSmgr on the foreign
> table, which has 0/0/0 rellocator. That creates an SMgrRelation for
> 0/0/0, and sets the foreign table's relcache entry as its owner. If you
> then call ANALYZE on another foreign table, it also calls
> RelationGetSmgr with 0/0/0 rellocator, returning the same SMgrRelation
> entry, and changes its owner to the new relcache entry. That doesn't
> make much sense and it's pretty accidental that it works at all, so
> attached is a patch to avoid calling visibilitymap_count() on foreign
> tables.

This patch seems uncontroversial and independent of the others, so I 
committed it.

-- 
Heikki Linnakangas
Neon (https://neon.tech)

Commits

  1. Give SMgrRelation pointers a well-defined lifetime.

  2. Remove some obsolete smgrcloseall() calls.

  3. Don't try to open visibilitymap when analyzing a foreign table

  4. Invalidate smgr_targblock in smgrrelease().