Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
| От | Semab Tariq |
|---|---|
| Тема | Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data |
| Дата | |
| Msg-id | CABimMB4mRs9N3eivR-=qF9M8oWc5E6OX7GywsWF0DXN4P5gNEA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data (Noah Misch <noah@leadboat.com>) |
| Ответы |
Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
(Thomas Munro <thomas.munro@gmail.com>)
|
| Список | pgsql-bugs |
Hi Noah
Sandeep is on vacation. So I am looking into this
I am facing some issues while applying the patch
fatal: git apply: bad git-diff - expected /dev/null on line 4
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
Semab
В списке pgsql-bugs по дате отправления: