On Tue, Nov 18, 2025, 21:10 Shinya Kato wrote:
> On Wed, Nov 19, 2025 at 9:04 AM Masahiko Sawada
> > > Fixed, but I have a comment. I noticed
> minor wording inconsistencies,
> > > e.g., 'started' vs. 'initiated' and 'due to' vs. 'because of'. Should
> > > I unify these terms?
> >
> > +1
>
> It
On Wed, Nov 19, 2025 at 9:04 AM Masahiko Sawada
> > Fixed, but I have a comment. I noticed
minor wording inconsistencies,
> > e.g., 'started' vs. 'initiated' and 'due to' vs. 'because of'. Should
> > I unify these terms?
>
> +1
It seems the inconsistency between 'started' and 'initiated' has not
On Wed, Nov 12, 2025 at 8:50 PM Shinya Kato wrote:
>
> On Thu, Nov 13, 2025 at 11:11 AM Masahiko Sawada
> wrote:
> > +
> > +
> > + The trigger of the current vacuum operation. Possible values are:
> >
> > What caused the current VACUUM operation to be initiated. Possible value
On Thu, Nov 13, 2025 at 11:11 AM Masahiko Sawada wrote:
> Thank you for updating the patch!
Thank you for the review!
> How about the following changes for the documentation changes?
>
> +
> + The mode of the current vacuum operation. Possible values are:
>
> The mode in which the c
On Thu, Oct 30, 2025 at 12:39 AM Shinya Kato wrote:
>
> On Thu, Oct 30, 2025 at 8:40 AM Masahiko Sawada wrote:
> > > I have updated the patch according to your comments. I have modified
> > > this to display the behavior mode (normal, aggressive, failsafe) in
> > > the mode column,
> >
> > The ne
On Thu, Oct 30, 2025 at 8:40 AM Masahiko Sawada wrote:
> > I have updated the patch according to your comments. I have modified
> > this to display the behavior mode (normal, aggressive, failsafe) in
> > the mode column,
>
> The new 'mode' column with the possible three values looks good to me.
T
On Fri, Oct 24, 2025 at 12:15 AM Shinya Kato wrote:
>
> Thank you all for the reviews!
>
> On Wed, Oct 8, 2025 at 4:34 AM Masahiko Sawada wrote:
> >
> > On Tue, Oct 7, 2025 at 12:01 PM Nathan Bossart
> > wrote:
> > >
> > > On Tue, Oct 07, 2025 at 10:17:38AM -0700, Masahiko Sawada wrote:
> > > >
Thank you all for the reviews!
On Wed, Oct 8, 2025 at 4:34 AM Masahiko Sawada wrote:
>
> On Tue, Oct 7, 2025 at 12:01 PM Nathan Bossart
> wrote:
> >
> > On Tue, Oct 07, 2025 at 10:17:38AM -0700, Masahiko Sawada wrote:
> > > Right. I think we cannot display both things in one mode column. Since
On Thu, Oct 16, 2025 at 2:17 PM Michael Paquier wrote:
>
> On Thu, Oct 09, 2025 at 10:07:17AM -0500, Sami Imseih wrote:
> >> IIUC are you suggesting I add such a last_autovacuum_reason column to
> >> pg_stat_all_tables, which would be populated with one of the following
> >> values?
> >> - autovac
On Thu, Aug 14, 2025 at 08:12:55PM +0900, Shinya Kato wrote:
> I would like to propose a patch that enhances the
> pg_stat_progress_vacuum view by adding a mode column. The patch is
> attached.
>
> Although it is possible to identify an anti-wraparound VACUUM through
> the process title (to preven
On Tue, Oct 07, 2025 at 11:50:46AM -0400, Robert Treat wrote:
> On Tue, Oct 7, 2025 at 11:04 AM Nathan Bossart
> wrote:
>> I wonder if we should also add "aggressive".
>
> I don't think so. I feel like the point of the mode is to answer "why
> is this vacuum running" not "how is it operating und
On Thu, Oct 09, 2025 at 10:07:17AM -0500, Sami Imseih wrote:
>> IIUC are you suggesting I add such a last_autovacuum_reason column to
>> pg_stat_all_tables, which would be populated with one of the following
>> values?
>> - autovacuum_vacuum_threshold
>> - autovacuum_vacuum_insert_threshold
>> - au
> > I wonder if we could be even more granular
> > for the "normal autovacuum" case and point to the reason the table was
> > chosen. For example, was it the insert threshold, the update/delete
> > threshold, etc.?
>
> Sounds like reasonable information. I guess we might want to have such
> infor
On Tue, Oct 7, 2025 at 12:01 PM Nathan Bossart wrote:
>
> On Tue, Oct 07, 2025 at 10:17:38AM -0700, Masahiko Sawada wrote:
> > Right. I think we cannot display both things in one mode column. Since
> > both manual vacuums and anti-wraparound autovacuums can enter the
> > failsafe mode dynamically,
> > > > I wonder if we could be even more granular
> > > > for the "normal autovacuum" case and point to the reason the table was
> > > > chosen. For example, was it the insert threshold, the update/delete
> > > > threshold, etc.?
> > >
> > > Sounds like reasonable information. I guess we might w
On Tue, Oct 07, 2025 at 10:17:38AM -0700, Masahiko Sawada wrote:
> Right. I think we cannot display both things in one mode column. Since
> both manual vacuums and anti-wraparound autovacuums can enter the
> failsafe mode dynamically, if we show "failsafe" in the mode column,
> we would lose the in
On Tue, Oct 7, 2025 at 9:26 AM Nathan Bossart wrote:
>
> On Tue, Oct 07, 2025 at 11:50:46AM -0400, Robert Treat wrote:
> > On Tue, Oct 7, 2025 at 11:04 AM Nathan Bossart
> > wrote:
> >> I wonder if we should also add "aggressive".
> >
> > I don't think so. I feel like the point of the mode is to
On Tue, Oct 7, 2025 at 11:04 AM Nathan Bossart wrote:
> On Thu, Aug 14, 2025 at 08:12:55PM +0900, Shinya Kato wrote:
> > I would like to propose a patch that enhances the
> > pg_stat_progress_vacuum view by adding a mode column. The patch is
> > attached.
> >
> > Although it is possible to identif
On Wed, Oct 8, 2025 at 12:04 AM Nathan Bossart wrote:
>
> > I was able to manually verify the failsafe mode's behavior by using
> > the existing test script at
> > src/test/modules/xid_wraparound/t/001_emergency_vacuum.pl. This script
> > successfully triggered the failsafe condition and the view
On Wed, Oct 8, 2025 at 4:34 AM Masahiko Sawada wrote:
>
> On Tue, Oct 7, 2025 at 12:01 PM Nathan Bossart
> wrote:
> >
> > On Tue, Oct 07, 2025 at 10:17:38AM -0700, Masahiko Sawada wrote:
> > > Right. I think we cannot display both things in one mode column. Since
> > > both manual vacuums and an
> On Tue, Oct 07, 2025 at 12:45:12PM -0500, Sami Imseih wrote:
> > The vacuum command detail can now be determined from
> > pg_stat_activity.query by joining with pg_stat_progress_vacuum, right?
> > I don't see why this is not sufficient, especially because it already
> > indicates how the vacuum w
On Wed, Oct 8, 2025 at 4:40 AM Sami Imseih wrote:
>
> > > I wonder if we could be even more granular
> > > for the "normal autovacuum" case and point to the reason the table was
> > > chosen. For example, was it the insert threshold, the update/delete
> > > threshold, etc.?
> >
> > Sounds like r
On Tue, Oct 07, 2025 at 12:45:12PM -0500, Sami Imseih wrote:
> The vacuum command detail can now be determined from
> pg_stat_activity.query by joining with pg_stat_progress_vacuum, right?
> I don't see why this is not sufficient, especially because it already
> indicates how the vacuum was trigger
I am bit late to this thread, but I have a comment.
> This patch introduces a mode column to provide this visibility. The
> possible values are:
> - normal: A standard, user-initiated VACUUM or a regular autovacuum run.
> - anti-wraparound: An autovacuum run launched specifically to prevent
> tran
On Fri, 15 Aug 2025 at 09:19, Shinya Kato wrote:
eager".
>
> Unless there’s a strong preference otherwise, I’d like to keep
> “anti-wraparound” and “failsafe” as-is, and keep “normal” (or possibly
> “plain”/“regular” if that reads better).
OK.
I have tested the patch a bit, and noticed that `mo
On Thu, Aug 14, 2025 at 9:20 PM Kirill Reshke wrote:
>
> On Thu, 14 Aug 2025 at 16:13, Shinya Kato wrote:
>
> > This patch introduces a mode column to provide this visibility. The
> > possible values are:
> > - normal: A standard, user-initiated VACUUM or a regular autovacuum run.
> > - anti-wrap
On Thu, 14 Aug 2025 at 16:13, Shinya Kato wrote:
> This patch introduces a mode column to provide this visibility. The
> possible values are:
> - normal: A standard, user-initiated VACUUM or a regular autovacuum run.
> - anti-wraparound: An autovacuum run launched specifically to prevent
> transa
Hi hackers,
I would like to propose a patch that enhances the
pg_stat_progress_vacuum view by adding a mode column. The patch is
attached.
Although it is possible to identify an anti-wraparound VACUUM through
the process title (to prevent wraparound) or specific log entries, it
would be significa
28 matches
Mail list logo
