I wrote:
> Yeah. I think we've had quite enough of the stats-transmission-related
> failures, and they're no longer proving anything about the original
> problem. So I will go do what I proposed in mid-July and revert the
> stats queries, while keeping the reltuples/relpages check. (I'd kind
> o
Thomas Munro writes:
> On Wed, Jul 24, 2019 at 11:59 AM Thomas Munro wrote:
>> On Tue, Jul 16, 2019 at 12:21 PM Tom Lane wrote:
>>> In the meantime, we've had *lots* of buildfarm failures in the
>>> added pg_stat_all_tables query, which indicate that indeed the
>>> stats collector mechanism isn'
On Wed, Jul 24, 2019 at 11:59 AM Thomas Munro wrote:
> On Tue, Jul 16, 2019 at 12:21 PM Tom Lane wrote:
> > In the meantime, we've had *lots* of buildfarm failures in the
> > added pg_stat_all_tables query, which indicate that indeed the
> > stats collector mechanism isn't terribly reliable. But
On Tue, Jul 16, 2019 at 12:21 PM Tom Lane wrote:
> In the meantime, we've had *lots* of buildfarm failures in the
> added pg_stat_all_tables query, which indicate that indeed the
> stats collector mechanism isn't terribly reliable. But that
> doesn't directly prove anything about the original pro
Andres Freund writes:
> On 2019-07-17 11:53:48 -0400, Tom Lane wrote:
>> A brute-force way to fix this (or at least reduce the odds quite a bit)
>> would be to have sanity_check.sql issue a CHECKPOINT before its VACUUM,
>> thereby guaranteeing that none of these pages are still in need of being
>>
On 2019-07-17 11:53:48 -0400, Tom Lane wrote:
> David Rowley writes:
> > Surely it can't be that since that just sets what *pages gets set to.
> > Tom mentioned that following was returning 0 pages and tuples:
>
> > -- Temporary hack to investigate whether extra vacuum/analyze is happening
> > se
David Rowley writes:
> Surely it can't be that since that just sets what *pages gets set to.
> Tom mentioned that following was returning 0 pages and tuples:
> -- Temporary hack to investigate whether extra vacuum/analyze is happening
> select relname, relpages, reltuples
> from pg_class
> where
On Wed, 17 Jul 2019 at 07:23, Andres Freund wrote:
>
> Hi,
>
> On 2019-07-15 21:12:32 -0400, Tom Lane wrote:
> > But I bet that these tables forming
> > an inheritance hierarchy (with multiple inheritance even) does
> > have something to do with it somehow, because if this were a
> > generic VACUU
Hi,
On 2019-07-15 21:12:32 -0400, Tom Lane wrote:
> But I bet that these tables forming
> an inheritance hierarchy (with multiple inheritance even) does
> have something to do with it somehow, because if this were a
> generic VACUUM bug surely we'd be seeing it elsewhere.
It's possible that it's
I wrote:
> So that data-collection patch has been in place for nearly 2 months
> (since 2019-05-21), and in that time we've seen a grand total of
> no repeats of the original problem, as far as I've seen.
Oh ... wait a minute. I decided to go scrape the buildfarm logs to
confirm my impression tha
[ reviving a thread that's been idle for awhile ]
I wrote:
> Thomas Munro writes:
>> Huh, idiacanthus failed showing vacuum_count 0, in select_parallel.
>> So ... the VACUUM command somehow skipped those tables?
> No, because the reltuples counts are correct. I think what we're
> looking at the
On Mon, May 20, 2019 at 11:15:47PM -0400, Tom Lane wrote:
> I got around to excavating in the buildfarm archives, and found a round
> dozen of more-or-less-similar incidents. I went back 18 months, which
> by coincidence (i.e., I didn't realize it till just now) is just about
> the time since 624e
Thomas Munro writes:
> Huh, idiacanthus failed showing vacuum_count 0, in select_parallel.
> So ... the VACUUM command somehow skipped those tables?
No, because the reltuples counts are correct. I think what we're
looking at there is the stats collector dropping a packet that
told it about vacuu
On Wed, May 22, 2019 at 2:39 AM Tom Lane wrote:
> David Rowley writes:
> > I did add the following query just before the failing one and included
> > the expected output from below. The tests pass for me in make check
> > and the post-upgrade test passes in make check-world too. I guess we
> >
David Rowley writes:
> I did add the following query just before the failing one and included
> the expected output from below. The tests pass for me in make check
> and the post-upgrade test passes in make check-world too. I guess we
> could commit that and see if it fails along with the other
Thomas Munro writes:
> On Mon, May 20, 2019 at 4:46 PM Tom Lane wrote:
>> Note that in the discussion that led up to 624e440a, we never did
>> think that we'd completely explained the original irreproducible
>> failure.
>>
>> I think I've seen a couple of other cases of this same failure
>> in t
On Tue, 21 May 2019 at 11:32, Thomas Munro wrote:
>
> On Mon, May 20, 2019 at 4:46 PM Tom Lane wrote:
> > Thomas Munro writes:
> > > Here's a one-off regression test failure of a sort that commit
> > > 624e440a intended to fix.
> >
> > Note that in the discussion that led up to 624e440a, we neve
Thomas Munro writes:
> On Mon, May 20, 2019 at 4:46 PM Tom Lane wrote:
>> Note that in the discussion that led up to 624e440a, we never did
>> think that we'd completely explained the original irreproducible
>> failure.
> I think it might be dependent on incidental vacuum/analyze activity
> havi
On Mon, May 20, 2019 at 4:46 PM Tom Lane wrote:
> Thomas Munro writes:
> > Here's a one-off regression test failure of a sort that commit
> > 624e440a intended to fix.
>
> Note that in the discussion that led up to 624e440a, we never did
> think that we'd completely explained the original irrepro
Thomas Munro writes:
> Here's a one-off regression test failure of a sort that commit
> 624e440a intended to fix.
Note that in the discussion that led up to 624e440a, we never did
think that we'd completely explained the original irreproducible
failure.
I think I've seen a couple of other cases
Hi,
Here's a one-off regression test failure of a sort that commit
624e440a intended to fix. a_star unexpectedly sorted higher. I
checked the space weather forecast for this morning but no sign of
solar flares. More seriously, it did the same in all 3 Parallel
Append queries. Recent commits lo
21 matches
Mail list logo
