Re: Re: PGroonga index-only scan problem with yesterday’s PostgreSQL updates

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Anders Kaseorg <andersk(at)mit(dot)edu>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Sutou Kouhei <kou(at)clear-code(dot)com>
Subject: Re: Re: PGroonga index-only scan problem with yesterday’s PostgreSQL updates
Date: 2022-02-12 17:25:03
Message-ID: 2285771.1644686703@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Anders Kaseorg <andersk(at)mit(dot)edu> writes:
> On 2/11/22 15:57, Tom Lane wrote:
>> Possibly same issue I just fixed?
>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e5691cc9170bcd6c684715c2755d919c5a16fea2

> Yeah, that does seem to fix my test cases. Thanks!

> Any chance this will make it into minor releases sooner than three
> months from now? I know extra minor releases are unusual, but this
> regression will be critical at least for self-hosted Zulip users and
> presumably other PGroonga users.

I don't know that we'd go that far ... maybe if another bad problem
turns up. In the meantime, though, I do have a modest suggestion:
it would not be too hard to put some defenses in place against another
such bug. The faulty commit was in our tree for a month and nobody
reported a problem, which is annoying. Do you want to think about doing
your testing against git branch tips, rather than the last released
versions? Making a new build every few days would probably be plenty
fast enough.

An even slicker answer would be to set up a PG buildfarm machine
that, in addition to the basic tests, builds PGroonga against the
new PG sources and runs your tests. Andrew's machine "crake" does
that for RedisFDW and BlackholeFDW, and the source code for at least
the latter module is in the buildfarm client distribution.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2022-02-12 17:40:06 Re: pgsql: Add TAP test to automate the equivalent of check_guc
Previous Message Tom Lane 2022-02-12 16:50:00 Re: pgsql: Add TAP test to automate the equivalent of check_guc