| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Extending SMgrRelation lifetimes |
| Date: | 2023-12-08 07:20:26 |
| Message-ID: | 8d0f8c76-fb2e-4e8b-a653-df0459c50b21@iki.fi |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2023-12-08 07:31:53 | Re: Memory consumed by paths during partitionwise join planning |
| Previous Message | Alexander Pyhalov | 2023-12-08 07:13:36 | Re: Assert failure on 'list_member_ptr(rel->joininfo, restrictinfo)' |