Re: [PATCH] src/test/modules/dummy_index -- way to test reloptions from inside of access method

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
Cc: Dent John <denty(at)qqdd(dot)eu>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: [PATCH] src/test/modules/dummy_index -- way to test reloptions from inside of access method
Date: 2019-09-18 22:51:09
Message-ID: CA+hUKG+8294zbN_k=QDgcW2TFia5TqsTR8nJLyYU+_C8vUTmrg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 19, 2019 at 7:58 AM Nikolay Shaplov <dhyan(at)nataraj(dot)su> wrote:
> В Fri, 2 Aug 2019 11:12:35 +1200
> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> пишет:
>
> > While moving this to the September CF, I noticed this failure:
> >
> > test reloptions ... FAILED 32 ms
>
> Do you have any idea, how to reproduce this? I tried this patch on
> current master, and did not get result you are talking about.
> Is it still there for you BTW?

Hi Nikolay,

Yeah, it's still happening on Travis:

https://travis-ci.org/postgresql-cfbot/postgresql/builds/586714100

Although the "reloptions" tests passes when it's run as part of the
regular test schedule (ie "make check"), the patch also runs it from
src/test/modules/dummy_index_am/Makefile ("REGRESS = reloptions"), and
when it runs in that context it fails. Cfbot is simply running "make
check-world".

Let's see if I can see this on my Mac... yep, with "make -C
src/test/modules/dummy_index_am directory check" I see a similar
failure with "ERROR: unrecognized lock mode: 2139062143". I changed
that to a PANIC and got a core file containing this stack:

frame #4: 0x00000001051e6572 postgres`elog_finish(elevel=22,
fmt="unrecognized lock mode: %d") at elog.c:1365:2
frame #5: 0x0000000104ff033a
postgres`LockAcquireExtended(locktag=0x00007ffeeb14bc28,
lockmode=2139062143, sessionLock=false, dontWait=false,
reportMemoryError=true, locallockp=0x00007ffeeb14bc20) at lock.c:756:3
frame #6: 0x0000000104fedaed postgres`LockRelationOid(relid=16397,
lockmode=2139062143) at lmgr.c:116:8
frame #7: 0x0000000104c056f2
postgres`RangeVarGetRelidExtended(relation=0x00007fbd0f000b58,
lockmode=2139062143, flags=0,
callback=(postgres`RangeVarCallbackForAlterRelation at
tablecmds.c:14834), callback_arg=0x00007fbd0f000d60) at
namespace.c:379:4
frame #8: 0x0000000104d4b14d
postgres`AlterTableLookupRelation(stmt=0x00007fbd0f000d60,
lockmode=2139062143) at tablecmds.c:3445:9
frame #9: 0x000000010501ff8b
postgres`ProcessUtilitySlow(pstate=0x00007fbd10800d18,
pstmt=0x00007fbd0f0010b0, queryString="ALTER INDEX test_idx SET
(int_option = 3);", context=PROCESS_UTILITY_TOPLEVEL,
params=0x0000000000000000, queryEnv=0x0000000000000000,
dest=0x00007fbd0f0011a0, completionTag="") at utility.c:1111:14
frame #10: 0x000000010501f480
postgres`standard_ProcessUtility(pstmt=0x00007fbd0f0010b0,
queryString="ALTER INDEX test_idx SET (int_option = 3);",
context=PROCESS_UTILITY_TOPLEVEL, params=0x0000000000000000,
queryEnv=0x0000000000000000, dest=0x00007fbd0f0011a0,
completionTag="") at utility.c:927:4

AlterTableGetLockLevel() returns that crazy lockmode value, becase it
calls AlterTableGetRelOptionsLockLevel(), I suspect with a garbage
defList, but I didn't dig further.

--
Thomas Munro
https://enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-09-18 23:41:21 Re: Define jsonpath functions as stable
Previous Message Chapman Flack 2019-09-18 22:47:15 Re: Define jsonpath functions as stable