On 2025-May-08, Michael Paquier wrote:
> Seems worth doing to simplify the code in the long-run, even if these
> require a case-by-case manual lookup.
Yeah, I don't think we can take a patch that simply removes everything
that this report mentions, because some of the includes (especially the
sys
On Wed, May 07, 2025 at 05:56:55PM +, Bertrand Drouvot wrote:
> FWIW, please find attached a subset of the initial report that focus on
> the "is not used directly" warnings.
Seems worth doing to simplify the code in the long-run, even if these
require a case-by-case manual lookup. Did you c
Hi,
On Wed, May 07, 2025 at 07:28:01AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Wed, May 07, 2025 at 09:10:17AM +0900, Michael Paquier wrote:
> > On Mon, May 05, 2025 at 04:33:20PM +0300, Ilia Evdokimov wrote:
> > > While reviewing the import/export statistics, I noticed that relation
> > > lo
Hi,
On Wed, May 07, 2025 at 09:10:17AM +0900, Michael Paquier wrote:
> On Mon, May 05, 2025 at 04:33:20PM +0300, Ilia Evdokimov wrote:
> > While reviewing the import/export statistics, I noticed that relation
> > locking are handled via relation_open() and relation_close() in
> > stats_lock_check_
On Mon, May 05, 2025 at 04:33:20PM +0300, Ilia Evdokimov wrote:
> While reviewing the import/export statistics, I noticed that relation
> locking are handled via relation_open() and relation_close() in
> stats_lock_check_privileges(), and no calls to other lock-manager routines
> are actually used
Hi hackers,
While reviewing the import/export statistics, I noticed that relation
locking are handled via relation_open() and relation_close() in
stats_lock_check_privileges(), and no calls to other lock-manager
routines are actually used there. As a result, the inclusion of the
lock-manager
