Re: CREATE UNLOGGED TABLE seq faults when debug_discard_caches=1 - Mailing list pgsql-hackers

From David Geier
Subject Re: CREATE UNLOGGED TABLE seq faults when debug_discard_caches=1
Date
Msg-id f17a1cf0-1219-bfa3-09ae-a2271d789a9d@gmail.com
Whole thread Raw
In response to Re: CREATE UNLOGGED TABLE seq faults when debug_discard_caches=1  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: CREATE UNLOGGED TABLE seq faults when debug_discard_caches=1
List pgsql-hackers
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
>



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Allow single table VACUUM in transaction block
Next
From: Tomas Vondra
Date:
Subject: Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes