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 happe
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 Sat, Mar 30, 2019 at 08:16:21AM -0400, Andrew Dunstan wrote:
> It's really just a matter of housekeeping as I see it, so probably
> DEBUG1 is right.
Okay, I'll use that then.
--
Michael
signature.asc
Description: PGP signature
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 mak
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 do
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. Perhap
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, it
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
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
>>> instea
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 find
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 com
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 singl
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 improve
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. The
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. I
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 USE_ASSERT_CH
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 c
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 @ fr
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 aggressive
> 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 b
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 backend,.wraparoun
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 sp
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
A
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 wa
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
32 matches
Mail list logo
