Horton
Menu

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

Semab Tariq <semab.tariq@enterprisedb.com>

View thread
From: Semab Tariq <semab.tariq@enterprisedb.com>
To: Noah Misch <noah@leadboat.com>
Cc: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, Andrey Borodin <x4mmm@yandex-team.ru>, Andres Freund <andres@anarazel.de>, 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>
Date: 2021-11-03T08:03:56Z
Lists: pgsql-bugs 
Hi Noah

Sandeep is on vacation. So I am looking into this

I am facing some issues while applying the patch

bash-4.1$ git apply step-to-crash-v0.patch
fatal: git apply: bad git-diff - expected /dev/null on line 4
bash-4.1$ patch -p1 < step-to-crash-v0.patch
Hmm... I can't seem to find a patch in there anywhere.

Then i decided to manually create that
src/test/subscription/t/080_step_equalTupleDescs.pl file and placed the
content there once file is created i run this command make -C
src/test/subscription check PROVE_TESTS=t/080_step_equalTupleDescs.pl but
it didn't generated any
src/test/subscription/tmp_check/log/regress_log_080_step_equalTupleDescs
file

Also, I get this at the end of the make command
TAP tests not enabled. Try configuring with --enable-tap-tests

After enabling tap tests and executing the configure command again I get
this error message

checking for fop... no
checking for dbtoepub... no
checking for perl module IPC::Run 0.79... no
checking for perl module Test::More 0.87... no
checking for perl module Time::HiRes 1.52... ok
configure: error: Additional Perl modules are required to run TAP tests

Seems like can't enable tap tests with current frameworks



On Wed, Nov 3, 2021 at 9:42 AM Noah Misch <noah@leadboat.com> wrote:

> On Tue, Nov 02, 2021 at 06:20:42AM +0530, Sandeep Thakkar wrote:
> > (gdb) frame 1
> >
> > #1  0x40000000003fdc00:0 in equalTupleDescs (tupdesc1=0x60000000001f65e0,
> >
> >     tupdesc2=0x60000000001fba08)
> >
> ...
> > (gdb) p tupdesc2->attrs[2]
> >
> > $6 = {attrelid = 27272, attname = {data = "b", '\000' <repeats 62
> times>},
> >   atttypid = 19, attstattarget = -1, attlen = 64, attnum = 3, attndims =
> 0,
> >   attcacheoff = -1, atttypmod = -1, attbyval = false, attalign = 99 'c',
> >   attstorage = 112 'p', attcompression = 0 '\000', attnotnull = false,
> >   atthasdef = false, atthasmissing = false, attidentity = 0 '\000',
> >   attgenerated = 0 '\000', attisdropped = false, attislocal = true,
> >   attinhcount = 0, attcollation = 950}
>
> That looks healthy.  Since gdb isn't giving line numbers, let's single-step
> from the start of the function and see if that is informative.  Please
> apply
> the attached patch, which just adds a test file.  Then run "make -C
> src/test/subscription check PROVE_TESTS=t/080_step_equalTupleDescs.pl" and
> attach
> src/test/subscription/tmp_check/log/regress_log_080_step_equalTupleDescs
> in a
> reply to this email.
>
> On Mon, Nov 01, 2021 at 12:01:08AM +0500, Andrey Borodin wrote:
> > So far I didn't come up with a clear understanding how this might happen.
>
> Agreed.
>
> > The only idea I have:
> > 1. It seems equalTupleDescs() got two valid pointers, probably with
> broken data.
> > 2. Maybe relation->rd_rel (alloceted just before relation->rd_att) was
> used incorrectly?
> > 3. This could happen if CLASS_TUPLE_SIZE is calculated wrong. Don't we
> need to MAXALIGN everything due to added sizeof(relminmxid)?
> > #define CLASS_TUPLE_SIZE \
> >      (offsetof(FormData_pg_class,relminmxid) + sizeof(TransactionId))
>
> See the comment at overread_tuplestruct_pg_cast for the reason why I think
> that can't cause an actual malfunction.  Still, there's some possibility of
> this being the explanation.
>


-- 
Thanks & Regards,
Semab

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.