From: | David Geier <geidav(dot)pg(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: CREATE UNLOGGED TABLE seq faults when debug_discard_caches=1 |
Date: | 2022-11-18 12:43:31 |
Message-ID: | f17a1cf0-1219-bfa3-09ae-a2271d789a9d@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2022-11-18 13:00:06 | Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes |
Previous Message | Simon Riggs | 2022-11-18 12:04:02 | Re: Allow single table VACUUM in transaction block |