Re: Parallel Append subplan order instability on aye-aye

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel Append subplan order instability on aye-aye
Date: 2019-05-21 00:43:03
Message-ID: CAKJS1f-KovGF5-j8xMdMufrF-i=dJqmS=nh0Y3=pBtvLnAN6hw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 21 May 2019 at 11:32, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> On Mon, May 20, 2019 at 4:46 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Thomas Munro <thomas(dot)munro(at)gmail(dot)com> 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 of this same failure
> > in the buildfarm recently, but too tired to go looking right now.
>
> I think it might be dependent on incidental vacuum/analyze activity
> having updated reltuples. With the attached script, I get the two
> plan variants depending on whether I comment out "analyze a_star". I
> guess we should explicitly analyze these X_star tables somewhere?

That's the only theory I came up with yesterday when thinking about
this. We can't really go adding an ANALYZE in a test in a parallel
group though since there'd be race conditions around other parallel
tests which could cause plan changes.

At the moment, these tables are only vacuumed in sanity_check.sql,
which as you can see is run by itself.

# ----------
# sanity_check does a vacuum, affecting the sort order of SELECT *
# results. So it should not run parallel to other tests.
# ----------
test: sanity_check

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 mentioned
failure. Alternatively, we could just invent some local tables
instead of using the ?_star tables and analyze them just before the
test, although, that does not guarantee a fix as there may be
something else to blame that we've not thought of.

select relname,last_vacuum is null,last_analyze is
null,last_autovacuum is null,last_autoanalyze is null from
pg_stat_all_tables where relname like '__star' order by relname;
relname | ?column? | ?column? | ?column? | ?column?
---------+----------+----------+----------+----------
a_star | f | t | t | t
b_star | f | t | t | t
c_star | f | t | t | t
d_star | f | t | t | t
e_star | f | t | t | t
f_star | f | t | t | t
(6 rows)

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2019-05-21 00:47:54 Re: PostgreSQL 12: Feature Highlights
Previous Message David Rowley 2019-05-21 00:33:54 Re: Caveats from reloption toast_tuple_target