Re: Parallel Append subplan order instability on aye-aye

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel Append subplan order instability on aye-aye
Date: 2019-05-22 04:24:35
Message-ID: CA+hUKGJLgTy36PLGcMJWFqaYwyHWugtmYjaZD179z_FcxHp9cQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 22, 2019 at 2:39 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> 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 mentioned
> > failure.
>
> I'm thinking this is a good idea, although I think we could be more
> aggressive about the data collected, as attached. Since all of these
> ought to be single-page tables, the relpages and reltuples counts
> should be machine-independent. In theory anyway.

Huh, idiacanthus failed showing vacuum_count 0, in select_parallel.
So ... the VACUUM command somehow skipped those tables?

--
Thomas Munro
https://enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-05-22 04:44:35 Re: Parallel Append subplan order instability on aye-aye
Previous Message Alexander Korotkov 2019-05-22 03:54:39 Re: PostgreSQL 12 Beta 1 press release draft