Re: ALTER TABLE ALTER COLUMN SET TYPE crash
От | Bruce Momjian |
---|---|
Тема | Re: ALTER TABLE ALTER COLUMN SET TYPE crash |
Дата | |
Msg-id | 20200825155544.GG32540@momjian.us обсуждение исходный текст |
Ответ на | Re: ALTER TABLE ALTER COLUMN SET TYPE crash (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: ALTER TABLE ALTER COLUMN SET TYPE crash
|
Список | pgsql-bugs |
On Tue, Aug 25, 2020 at 03:05:11PM +0900, Michael Paquier wrote: > On Tue, Aug 25, 2020 at 02:14:06PM +1000, Robins Tharakan wrote: > > Unlike a recently reported similar issue, executing the following ALTER > > TABLE on the regression database crashes Postgres (master). > > > > Admittedly it doesn't do anything constructive (and am new to the tool), > > but do let me know if such reports are interesting and / or if you need > > more details for reproduction. > > Such reports are constructive! I can reproduce the crash here down to > 9.5. From what I can see, the problem comes from ATRewriteTable() -> > ExecEvalExpr() when we evaluate expressions with inputs coming from > the old tuple. It looks like a memory corruption issue or a context > issue at quick glance, and I cannot get a clean backtrace. OK, I have generated a attached backtrace by manually walking down through the stack using break points. Notice len2 on the top line: #0 varstr_cmp (arg1=0x55e0ef64262c "\252\061\306BT\026", len1=21, arg2=0x7f274db17ebc "-\317\303=T\026", len2=-4, collid=100) at varlena.c:1633 ------- -4 is not a good len. I will do more research to see why that -4 len is happening. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Вложения
В списке pgsql-bugs по дате отправления: