Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Andrei Zubkov <zubkov(at)moonset(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Date: 2023-10-24 15:03:04
Message-ID: e74748f5-efb7-4798-a9ca-02e5f834efa3@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 24.10.23 14:40, Julien Rouhaud wrote:
> On Tue, Oct 24, 2023 at 6:57 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>>
>> On 24.10.23 09:58, Andrei Zubkov wrote:
>>> During last moving to the current commitfest this patch have lost its
>>> reviewers list. With respect to reviewers contribution in this patch, I
>>> think reviewers list should be fixed.
>>
>> I don't think it's the purpose of the commitfest app to track how *has*
>> reviewed a patch. The purpose is to plan and allocate *current* work.
>> If we keep a bunch of reviewers listed on a patch who are not actually
>> reviewing the patch, then that effectively blocks new reviewers from
>> signing up and the patch will not make progress.
>>
>> Past reviewers should of course be listed in the commit message, the
>> release notes, etc. as appropriate.
>
> Really? Last time this topic showed up at least one committer said
> that they tend to believe the CF app more than digging the thread [1],
> and some other hackers mentioned other usage for being kept in the
> reviewer list. Since no progress has been made on the CF app since
> I'm not sure it's the best idea to drop reviewer names from patch
> entries generally.

There is a conflict between the two purposes. But it is clearly the
case that reviewers will more likely pick up patches that have no
reviewers assigned. So if you keep stale reviewer entries around, then
a patch that stays around for a while will never get reviewed again. I
think this is a significant problem at the moment, and I made it part of
my mission during the last commitfest to clean it up. If people want to
put the stale reviewer entries back in, that is possible, but I would
caution against that, because that would just self-sabotage those patches.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-10-24 15:07:29 Re: Replace references to malloc() in libpq documentation with generic language
Previous Message Peter Eisentraut 2023-10-24 14:53:44 Re: trying again to get incremental backup