Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data

Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>

From: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Noah Misch <noah@leadboat.com>, CM Team <cm@enterprisedb.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>, Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Geoghegan <pg@bowt.ie>, Andres Freund <andres@anarazel.de>
Date: 2021-10-30T08:14:56Z
Lists: pgsql-bugs
On Sat, Oct 30, 2021 at 1:29 PM Sandeep Thakkar <
sandeep.thakkar@enterprisedb.com> wrote:

>
>
> On Sat, Oct 30, 2021 at 12:56 PM Andrey Borodin <x4mmm@yandex-team.ru>
> wrote:
>
>>
>>
>> > 30 окт. 2021 г., в 11:09, Sandeep Thakkar <
>> sandeep.thakkar@enterprisedb.com> написал(а):
>> >
>> > On Thu, Oct 28, 2021 at 7:35 PM Noah Misch <noah@leadboat.com> wrote:
>> > On Sun, Oct 24, 2021 at 04:35:02PM -0700, Noah Misch wrote:
>> > > On Sat, Oct 23, 2021 at 10:00:28PM -0700, Noah Misch wrote:
>> > > > Pushed.
>> > >
>> > > cm@enterprisedb.com, could you post a stack trace from buildfarm
>> member
>> > > gharial failing in "make check"?  I'm looking for a trace from a
>> SIGSEGV like
>> > > those seen today:
>> > >
>> > >
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gharial&dt=2021-10-24%2016%3A19%3A05
>> > >
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gharial&dt=2021-10-24%2020%3A38%3A39
>> > >
>> > > Those SIGSEGV are all in ALTER TABLE.  My commits from this thread
>> probably
>> > > broke something, but I've run out of ideas, and my hpux boxes died.
>> >
>> > cm@enterprisedb.com, is this still in your queue, or not?  I am
>> somewhat
>> > concerned that the 2021-11-11 releases will contain a regression if the
>> > gharial failures remain undiagnosed.  I don't know how to diagnose them
>> > without your help.  (I currently can't justify reverting the suspect
>> bug fix
>> > on the basis of two master-branch-only failures in one buildfarm
>> member.)
>> >
>> > Sorry for responding late as this email was missed somehow :-(  I
>> checked the reports on the dashboard and there was a failure then but the
>> reports after 25th Oct looks fine. The back branches all look fine as well.
>> https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=gharial&br=HEAD
>> >
>> > Please let me know if I missed something
>>
>> Hi Sandeep, thank you for the response!
>>
>> Some failed runs on this animal indicate SegFault in places changed by
>> bugfix relevant to this thread. Fails were observed only on HEAD, but this
>> may be a result of concurrent nature of possible new bug. If there is a new
>> bug - this would affect upcoming point release. But we do not know for
>> sure. Other animals show no signs of any related SegFault.
>> Can you please run make check phase on this animal on HEAD multiple time
>> (preferably ~hundred times)? If some of this runs fail it's vital to
>> collect backtraces of run.
>>
>> Hi Andrew,
>
> OK I got it now. I've scheduled "./run_build.pl HEAD" on this animal to
> run multiple times in a day. Unfortunately, I can't run it ~100 times
> because it's a legacy (slow) server and also we run another animal (anole -
> with a different compiler) on the same server. Depending on the time every
> run on HEAD takes, I'll increase the frequency. Hope this helps.
>
> I've used "--force" option so that it ignores the last running status.
./run_build.pl --verbose --force HEAD


>
>
>> Many thanks!
>>
>> Best regards, Andrey Borodin.
>
>
>
> --
> Sandeep Thakkar
>
>
>

-- 
Sandeep Thakkar

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Improve contrib/amcheck's tests for CREATE INDEX CONCURRENTLY.

  2. Fix minor memory leaks in pg_dump.

  3. Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURRENTLY.

  4. Fix CREATE INDEX CONCURRENTLY for the newest prepared transactions.

  5. Add -w back to the flags for pg_ctl (re)start in PostgresNode

  6. Fix CREATE INDEX CONCURRENTLY for simultaneous prepared transactions.