Re: CREATE UNLOGGED TABLE seq faults when debug_discard_caches=1

Hi Tom,

Back-patching but keeping RelationOpenSgmr() for extensions sounds 
reasonable.

On a different note: are we frequently running our tests suites with 
debug_discard_caches=1 enabled?
It doesn't seem like. I just ran make check with debug_discard_caches=1 on

- latest master: everything passes.
- version 14.5: fails in create_index, create_index_spgist, create_view.

So the buggy code path is at least covered by the tests. But it seems 
like we could have found it earlier by regularly running with 
debug_discard_caches=1.

--
David Geier
(ServiceNow)

On 11/17/22 18:51, Tom Lane wrote:
> I wrote:
>> I wonder whether we ought to back-patch f10f0ae42.  We could
>> leave the RelationOpenSmgr macro in existence to avoid unnecessary
>> breakage of extension code, but stop using it within our own code.
> Concretely, about like this for v14 (didn't look at the older
> branches yet).
>
> I'm not sure whether to recommend that outside extensions switch to using
> RelationGetSmgr in pre-v15 branches.  If they do, they run a risk
> of compile failure should they be built against old back-branch
> headers.  Once compiled, though, they'd work against any minor release
> (since RelationGetSmgr is static inline, not something in the core
> backend).  So maybe that'd be good enough, and keeping their code in
> sync with what they need for v15 would be worth something.
>
> 			regards, tom lane
>