Re: [PATCH] src/test/modules/dummy_index -- way to test reloptionsfrom inside of access method
От | Thomas Munro |
---|---|
Тема | Re: [PATCH] src/test/modules/dummy_index -- way to test reloptionsfrom inside of access method |
Дата | |
Msg-id | CA+hUKG+8294zbN_k=QDgcW2TFia5TqsTR8nJLyYU+_C8vUTmrg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] src/test/modules/dummy_index -- way to test reloptions from inside of access method (Nikolay Shaplov <dhyan@nataraj.su>) |
Ответы |
Re: [PATCH] src/test/modules/dummy_index -- way to test reloptionsfrom inside of access method
(Michael Paquier <michael@paquier.xyz>)
|
Список | pgsql-hackers |
On Thu, Sep 19, 2019 at 7:58 AM Nikolay Shaplov <dhyan@nataraj.su> wrote: > В Fri, 2 Aug 2019 11:12:35 +1200 > Thomas Munro <thomas.munro@gmail.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
В списке pgsql-hackers по дате отправления: