Re: ALTER TABLE ALTER COLUMN SET TYPE crash - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: ALTER TABLE ALTER COLUMN SET TYPE crash
Date
Msg-id 20200825155544.GG32540@momjian.us
Whole thread Raw
In response to Re: ALTER TABLE ALTER COLUMN SET TYPE crash  (Michael Paquier <michael@paquier.xyz>)
Responses Re: ALTER TABLE ALTER COLUMN SET TYPE crash  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


Attachment

pgsql-bugs by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: invalid alloc size error possible in shm_mq
Next
From: Tom Lane
Date:
Subject: Re: ALTER TABLE ALTER COLUMN SET TYPE crash