On Mon, Jan 19, 2015 at 12:05:01PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jan 19, 2015 at 11:30 AM, Andres Freund
> > wrote:
> >> Sure, but the log isn't invisible. As mentioned one paragraph above, I
> >> don't think it's likely to ever be noticed in the client code in the
> >
Robert Haas writes:
> On Mon, Jan 19, 2015 at 11:30 AM, Andres Freund
> wrote:
>> Sure, but the log isn't invisible. As mentioned one paragraph above, I
>> don't think it's likely to ever be noticed in the client code in the
>> cases where it happens in production.
> Yes, that is my feeling as
On Mon, Jan 19, 2015 at 11:30 AM, Andres Freund wrote:
> On 2015-01-19 11:28:41 -0500, Tom Lane wrote:
>> Andres Freund writes:
>> > On 2015-01-19 11:16:09 -0500, Tom Lane wrote:
>> >> Possibly we need to improve the wording of that error message then.
>> >> When it was written, we really assumed
On 2015-01-19 11:28:41 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-01-19 11:16:09 -0500, Tom Lane wrote:
> >> Possibly we need to improve the wording of that error message then.
> >> When it was written, we really assumed that it was a can't-happen case
> >> and so didn't spend much
Andres Freund writes:
> On 2015-01-19 11:16:09 -0500, Tom Lane wrote:
>> Possibly we need to improve the wording of that error message then.
>> When it was written, we really assumed that it was a can't-happen case
>> and so didn't spend much effort on it. Perhaps it should become a
>> translatab
On Mon, Jan 19, 2015 at 11:16 AM, Tom Lane wrote:
> Robert Haas writes:
>> Sure, but nobody who is not a developer is going to care about that.
>> A typical user who sees "pgstat wait timeout", or doesn't, isn't going
>> to be able to make anything at all out of that.
>
> Possibly we need to impr
On 2015-01-19 11:16:09 -0500, Tom Lane wrote:
> Robert Haas writes:
> >> I'd be fine with changing the warning to LOG level rather than
> >> suppressing it entirely for the specific case of pgstat_vacuum_stat;
> >> but I do want to distinguish that case, wherein it's fair to conclude
> >> that obs
Robert Haas writes:
> Sure, but nobody who is not a developer is going to care about that.
> A typical user who sees "pgstat wait timeout", or doesn't, isn't going
> to be able to make anything at all out of that.
Possibly we need to improve the wording of that error message then.
When it was wri
On Mon, Jan 19, 2015 at 10:35 AM, Tom Lane wrote:
> If that were true I'd agree with you, but it's false on its face.
> A user who is actually examining the statistics might well want to
> know if they're significantly out of date. A very relevant example
> is that I've always wondered how come,
Robert Haas writes:
> On Mon, Jan 19, 2015 at 7:09 AM, Andres Freund wrote:
>> On 2015-01-18 21:33:25 -0500, Robert Haas wrote:
>>> I think this is too much of a good thing. I don't see any reason why
>>> autovacuum's statistics need to be fresher than normal, but I also
>>> don't see any reason
On Mon, Jan 19, 2015 at 7:09 AM, Andres Freund wrote:
> On 2015-01-18 21:33:25 -0500, Robert Haas wrote:
>> On Sun, Jan 18, 2015 at 4:09 PM, Tom Lane wrote:
>> > After looking at the code, the minimum-change alternative would be more or
>> > less as attached: first, get rid of the long-obsolete p
On 2015-01-18 21:33:25 -0500, Robert Haas wrote:
> On Sun, Jan 18, 2015 at 4:09 PM, Tom Lane wrote:
> > After looking at the code, the minimum-change alternative would be more or
> > less as attached: first, get rid of the long-obsolete proposition that
> > autovacuum workers need fresher-than-usu
On Sun, Jan 18, 2015 at 4:09 PM, Tom Lane wrote:
> After looking at the code, the minimum-change alternative would be more or
> less as attached: first, get rid of the long-obsolete proposition that
> autovacuum workers need fresher-than-usual stats; second, allow
> pgstat_vacuum_stat to accept st
On Sun, Jan 18, 2015 at 07:02:54PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Sun, Jan 18, 2015 at 04:09:29PM -0500, Tom Lane wrote:
> >> After looking at the code, the minimum-change alternative would be more or
> >> less as attached: first, get rid of the long-obsolete proposition that
>
Noah Misch writes:
> On Sun, Jan 18, 2015 at 04:09:29PM -0500, Tom Lane wrote:
>> After looking at the code, the minimum-change alternative would be more or
>> less as attached: first, get rid of the long-obsolete proposition that
>> autovacuum workers need fresher-than-usual stats; second, allow
On Sun, Jan 18, 2015 at 04:09:29PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Sat, Dec 27, 2014 at 07:55:05PM -0500, Tom Lane wrote:
> >> Or, much more simply, we could conclude that it's not that important
> >> if pgstat_vacuum_stat() is unable to get up-to-date stats, and rejigger
> >> t
Noah Misch writes:
> On Sat, Dec 27, 2014 at 07:55:05PM -0500, Tom Lane wrote:
>> To get back to that original complaint about buildfarm runs failing,
>> I notice that essentially all of those failures are coming from "wait
>> timeout" warnings reported by manual VACUUM commands. Now, VACUUM itse
On Sat, Dec 27, 2014 at 07:55:05PM -0500, Tom Lane wrote:
> To get back to that original complaint about buildfarm runs failing,
> I notice that essentially all of those failures are coming from "wait
> timeout" warnings reported by manual VACUUM commands. Now, VACUUM itself
> has no need to read
On Thu, Dec 25, 2014 at 09:14:36PM +0100, Andres Freund wrote:
> My guess is that a checkpoint happened at that time. Maybe it'd be a
> good idea to make pg_regress start postgres with log_checkpoints
> enabled? My guess is that we'd find horrendous 'sync' times.
+1, independent of $SUBJECT. How
19 matches
Mail list logo
