On Mon, Mar 23, 2020 at 06:41:50PM -0700, Andres Freund wrote:
> Which valid scenario can lead to this? Neither the comment, nor commit
> message explain it.
The commit message mentions that concurrent autovacuum jobs can lead
to the creation of non-aggressive and anti-wraparound jobs, which have
Hi,
On 2019-03-29 20:51:38 +0900, Michael Paquier wrote:
> So, coming back to this thread, and studying the problem again, it
> looks that the diagnostic that a non-aggressive, anti-wraparound
> vacuum could be triggered because the worker sees trouble in the
> force because of some activity
On Sat, Mar 30, 2019 at 10:12:33PM +0900, Michael Paquier wrote:
> Okay, I'll use that then.
And finally committed. I have changed the debug1 message so as "to
prevent wraparound" is used instead of "anti-wraparound". I have
noticed something which was also missing from all the patches proposed
On 3/29/19 9:08 PM, Michael Paquier wrote:
> On Fri, Mar 29, 2019 at 11:22:55AM -0300, Alvaro Herrera wrote:
>> Yeah, that looks good to me too. I wonder if we really need it as LOG
>> though; we don't say anything for actions unless they take more than the
>> min duration, so why say something
On Fri, Mar 29, 2019 at 11:22:55AM -0300, Alvaro Herrera wrote:
> Yeah, that looks good to me too. I wonder if we really need it as LOG
> though; we don't say anything for actions unless they take more than the
> min duration, so why say something for a no-op that takes almost no time?
> Maybe
On 2019-Mar-29, Michael Paquier wrote:
> On Fri, Mar 29, 2019 at 09:11:47AM -0400, Andrew Dunstan wrote:
> > + (errmsg_internal("found vacuum to prevent wraparound of
> > table \"%s.%s.%s\" to be not aggressive, so skipping",
> >
> > This might convey something to hackers, but I
On Fri, Mar 29, 2019 at 09:11:47AM -0400, Andrew Dunstan wrote:
> + (errmsg_internal("found vacuum to prevent wraparound of
> table \"%s.%s.%s\" to be not aggressive, so skipping",
>
> This might convey something to hackers, but I doubt it will convey much
> to regular users.
On 3/29/19 7:51 AM, Michael Paquier wrote:
> On Sat, Mar 09, 2019 at 10:15:37AM +0900, Michael Paquier wrote:
>> I am adding an open item about that. I think I could commit the
>> patch, but I need to study it a bit more first.
> So, coming back to this thread, and studying the problem again,
On Sat, Mar 09, 2019 at 10:15:37AM +0900, Michael Paquier wrote:
> I am adding an open item about that. I think I could commit the
> patch, but I need to study it a bit more first.
So, coming back to this thread, and studying the problem again, it
looks that the diagnostic that a non-aggressive,
On Fri, Mar 08, 2019 at 05:05:53PM -0500, Andrew Dunstan wrote:
> I notice that this seems never to have been acted on. I think we should
> apply this and remove the (confusing) message setting for the case we'll
> now be avoiding. If not we should at least comment there that this is a
> case we
On 10/9/18 5:15 AM, Kyotaro HORIGUCHI wrote:
> At Fri, 5 Oct 2018 15:35:04 +0900, Michael Paquier
> wrote in <20181005063504.gb14...@paquier.xyz>
>> On Fri, Oct 05, 2018 at 12:16:03PM +0900, Michael Paquier wrote:
>>> So, I have come back to this stuff, and finished with the attached
>>>
At Fri, 5 Oct 2018 15:35:04 +0900, Michael Paquier wrote
in <20181005063504.gb14...@paquier.xyz>
> On Fri, Oct 05, 2018 at 12:16:03PM +0900, Michael Paquier wrote:
> > So, I have come back to this stuff, and finished with the attached
> > instead, so as the assertion is in a single place. I
On Fri, Oct 05, 2018 at 12:16:03PM +0900, Michael Paquier wrote:
> So, I have come back to this stuff, and finished with the attached
> instead, so as the assertion is in a single place. I find that
> clearer. The comments have also been improved. Thoughts?
And so... I have been looking at
On Fri, Oct 5, 2018 at 12:16 PM Michael Paquier wrote:
>
> On Wed, Oct 03, 2018 at 04:37:29PM +0900, Masahiko Sawada wrote:
> > Thank you for the comment. Attached the updated patch.
>
> So, I have come back to this stuff, and finished with the attached
> instead, so as the assertion is in a
On Wed, Oct 03, 2018 at 04:37:29PM +0900, Masahiko Sawada wrote:
> Thank you for the comment. Attached the updated patch.
So, I have come back to this stuff, and finished with the attached
instead, so as the assertion is in a single place. I find that
clearer. The comments have also been
On Wed, Oct 03, 2018 at 04:37:29PM +0900, Masahiko Sawada wrote:
> Thank you for the comment. Attached the updated patch.
Thanks for the patch. This looks clean to me at quick glance, not
tested though..
--
Michael
signature.asc
Description: PGP signature
On Tue, Oct 2, 2018 at 11:15 PM Tom Lane wrote:
>
> Michael Paquier writes:
> > My brain is rather fried for the rest of the day... But we could just
> > be looking at using USE_ASSERT_CHECKING. Thoughts from other are
> > welcome.
>
> I'd go with folding the condition into a plain Assert.
Michael Paquier writes:
> My brain is rather fried for the rest of the day... But we could just
> be looking at using USE_ASSERT_CHECKING. Thoughts from other are
> welcome.
I'd go with folding the condition into a plain Assert. Then it's
obvious that no code is added in a non-assert build.
On Tue, Oct 02, 2018 at 01:18:01PM +0900, Masahiko Sawada wrote:
> I'm not sure both styles would be appropriate style in the postgres
> code so I would rather add elog(ERROR) instead. Thought?
My brain is rather fried for the rest of the day... But we could just
be looking at using
On Tue, Oct 2, 2018 at 9:11 AM Michael Paquier wrote:
>
> On Fri, Sep 28, 2018 at 01:53:14PM +0900, Masahiko Sawada wrote:
> > I agree. Can we fix this simply by the attached patch?
>
> Thanks for sending a patch.
>
> +/* autovacuum cannot be anti-wraparound and not aggressive vacuum */
> +
On Fri, Sep 28, 2018 at 01:53:14PM +0900, Masahiko Sawada wrote:
> I agree. Can we fix this simply by the attached patch?
Thanks for sending a patch.
+/* autovacuum cannot be anti-wraparound and not aggressive vacuum */
+Assert(aggressive);
+msgfmt = _("automatic aggressive vacuum to
On Tue, Sep 25, 2018 at 6:11 AM Alvaro Herrera wrote:
>
> On 2018-Sep-24, Sergei Kornilov wrote:
>
> > Hi
> >
> > > An autovacuum can't be just aggressive; it's either anti-wraparound or
> > > normal.
> > But autovacuum _can_ be aggressive and not anti-wraparound.
> > I build current master and
On 2018-Sep-24, Sergei Kornilov wrote:
> Hi
>
> > An autovacuum can't be just aggressive; it's either anti-wraparound or
> > normal.
> But autovacuum _can_ be aggressive and not anti-wraparound.
> I build current master and can see 3 different line types:
> 2018-09-24 23:47:31.500 MSK 27939 @
Hi
> An autovacuum can't be just aggressive; it's either anti-wraparound or normal.
But autovacuum _can_ be aggressive and not anti-wraparound.
I build current master and can see 3 different line types:
2018-09-24 23:47:31.500 MSK 27939 @ from [vxid:4/272032 txid:0] [] LOG:
automatic
> On Sep 24, 2018, at 1:29 PM, Andres Freund wrote:
>
> I'm very doubtful this is an improvement. Especially with the upcoming
> pluggable storage work making vacuumlazy.c heap specific, while vacuum.c
> stays generic. The concept of something like
> PROC_VACUUM_FOR_WRAPAROUND, should imo not
On 2018-09-24 18:25:46 +, Nasby, Jim wrote:
>
> > On Sep 21, 2018, at 12:43 PM, Andres Freund wrote:
> >
> >> But as far i can see it is possible have aggressive non-wraparound vacuum.
> >> One important difference - regular and aggressive regular can be canceled
> >> by
Hi,
On 2018-09-21 20:38:16 +0300, Sergei Kornilov wrote:
> > My first question was whether TWO of them were dead code ... isn't an
> > aggressive vacuum to prevent wraparound, and a vacuum to prevent
> > wraparound aggressive?
> Maybe i am wrong, aggressive autovacuum was your commit.
> Message
Hello, Robert
> My first question was whether TWO of them were dead code ... isn't an
> aggressive vacuum to prevent wraparound, and a vacuum to prevent
> wraparound aggressive?
Maybe i am wrong, aggressive autovacuum was your commit.
Message split was in b55509332f50f998b6e8b3830a51c5b9d8f666aa
On Fri, Sep 14, 2018 at 11:35 AM, Alvaro Herrera
wrote:
> On 2018-Sep-13, Michael Paquier wrote:
>> Improve autovacuum logging for aggressive and anti-wraparound runs
>>
>> A log message was being generated when log_min_duration is reached for
>> autovacuum on a given relation to indicate if it
On Fri, Sep 14, 2018 at 12:35:54PM -0300, Alvaro Herrera wrote:
> On 2018-Sep-13, Michael Paquier wrote:
>> Improve autovacuum logging for aggressive and anti-wraparound runs
>>
>> A log message was being generated when log_min_duration is reached for
>> autovacuum on a given relation to indicate
On 2018-Sep-13, Michael Paquier wrote:
> Improve autovacuum logging for aggressive and anti-wraparound runs
>
> A log message was being generated when log_min_duration is reached for
> autovacuum on a given relation to indicate if it was an aggressive run,
> and missed the point of mentioning if
31 matches
Mail list logo
