pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
BUG #17706: ALTER TYPE leads to crash
6+ messages / 4 participants
[nested] [flat]

* BUG #17706: ALTER TYPE leads to crash
@ 2022-12-07 20:16 PG Bug reporting form <noreply@postgresql.org>
  2022-12-08 04:16 ` Re: BUG #17706: ALTER TYPE leads to crash Richard Guo <guofenglinux@gmail.com>
  0 siblings, 1 reply; 6+ messages in thread

From: PG Bug reporting form @ 2022-12-07 20:16 UTC (permalink / raw)
  To: pgsql-bugs@lists.postgresql.org; +Cc: s.shinderuk@postgrespro.ru

The following bug has been logged on the website:

Bug reference:      17706
Logged by:          Sergey Shinderuk
Email address:      s.shinderuk@postgrespro.ru
PostgreSQL version: 15.1
Operating system:   Ubuntu 22.04
Description:        

With PL/pgSQL:

create type foo as (a int, b int);

create function bar() returns record as $$
declare
        r foo := row(123, 2^30);
begin
        alter type foo alter attribute b type text;
        return r;
end;
$$ language plpgsql;

postgres=# select bar();
server closed the connection unexpectedly
  This probably means the server terminated abnormally
  before or while processing the request.

LOG:  server process (PID 394076) was terminated by signal 11: Segmentation
fault

(Here 2^30 is interpreted as a string length.)


With a cursor:

postgres=# create type foo as (a int, b int);
CREATE TYPE
postgres=# begin;
BEGIN
postgres=*# declare c cursor for select (i, 2^30)::foo from
generate_series(1,10) i;
DECLARE CURSOR
postgres=*# fetch c;
      row       
----------------
 (1,1073741824)
(1 row)

postgres=*# fetch c;
      row       
----------------
 (2,1073741824)
(1 row)

postgres=*# alter type foo alter attribute b type text;
ALTER TYPE
postgres=*# fetch c;
server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: BUG #17706: ALTER TYPE leads to crash
  2022-12-07 20:16 BUG #17706: ALTER TYPE leads to crash PG Bug reporting form <noreply@postgresql.org>
@ 2022-12-08 04:16 ` Richard Guo <guofenglinux@gmail.com>
  2022-12-08 05:01   ` Re: BUG #17706: ALTER TYPE leads to crash David G. Johnston <david.g.johnston@gmail.com>
  0 siblings, 1 reply; 6+ messages in thread

From: Richard Guo @ 2022-12-08 04:16 UTC (permalink / raw)
  To: s.shinderuk@postgrespro.ru; pgsql-bugs@lists.postgresql.org

On Thu, Dec 8, 2022 at 4:51 AM PG Bug reporting form <noreply@postgresql.org>
wrote:

> With PL/pgSQL:
>
> create type foo as (a int, b int);
>
> create function bar() returns record as $$
> declare
>         r foo := row(123, 2^30);
> begin
>         alter type foo alter attribute b type text;
>         return r;
> end;
> $$ language plpgsql;
>
> postgres=# select bar();
> server closed the connection unexpectedly
>   This probably means the server terminated abnormally
>   before or while processing the request.
>
> LOG:  server process (PID 394076) was terminated by signal 11: Segmentation
> fault
>
> (Here 2^30 is interpreted as a string length.)


ISTM after the alter operation, the attribute description of 'b' has
been altered to cope with type text, but the data layout inside the heap
tuple stays unchanged.  So when we fetch attribute 'b', what we get is
an integer pointer into the tuple's data area storing value 2^30, due to
type text is not attbyval.

Then later we interpret that integer pointer as a varlena pointer, which
is not correct.

But I'm not sure how to fix it.  Is there an easy way to also alter the
data layout inside the tuple?

Thanks
Richard

^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: BUG #17706: ALTER TYPE leads to crash
  2022-12-07 20:16 BUG #17706: ALTER TYPE leads to crash PG Bug reporting form <noreply@postgresql.org>
  2022-12-08 04:16 ` Re: BUG #17706: ALTER TYPE leads to crash Richard Guo <guofenglinux@gmail.com>
@ 2022-12-08 05:01   ` David G. Johnston <david.g.johnston@gmail.com>
  2022-12-13 02:58     ` Re: BUG #17706: ALTER TYPE leads to crash Richard Guo <guofenglinux@gmail.com>
  0 siblings, 1 reply; 6+ messages in thread

From: David G. Johnston @ 2022-12-08 05:01 UTC (permalink / raw)
  To: Richard Guo <guofenglinux@gmail.com>; +Cc: s.shinderuk@postgrespro.ru; pgsql-bugs@lists.postgresql.org

On Wed, Dec 7, 2022 at 9:17 PM Richard Guo <guofenglinux@gmail.com> wrote:

>
> On Thu, Dec 8, 2022 at 4:51 AM PG Bug reporting form <
> noreply@postgresql.org> wrote:
>
>> With PL/pgSQL:
>>
>> create type foo as (a int, b int);
>>
>> create function bar() returns record as $$
>> declare
>>         r foo := row(123, 2^30);
>> begin
>>         alter type foo alter attribute b type text;
>>         return r;
>> end;
>> $$ language plpgsql;
>>
>> postgres=# select bar();
>> server closed the connection unexpectedly
>>   This probably means the server terminated abnormally
>>   before or while processing the request.
>>
>> LOG:  server process (PID 394076) was terminated by signal 11:
>> Segmentation
>> fault
>>
>> (Here 2^30 is interpreted as a string length.)
>
>
> ISTM after the alter operation, the attribute description of 'b' has
> been altered to cope with type text, but the data layout inside the heap
> tuple stays unchanged.  So when we fetch attribute 'b', what we get is
> an integer pointer into the tuple's data area storing value 2^30, due to
> type text is not attbyval.
>
> Then later we interpret that integer pointer as a varlena pointer, which
> is not correct.
>
> But I'm not sure how to fix it.  Is there an easy way to also alter the
> data layout inside the tuple?
>
>

^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: BUG #17706: ALTER TYPE leads to crash
  2022-12-07 20:16 BUG #17706: ALTER TYPE leads to crash PG Bug reporting form <noreply@postgresql.org>
  2022-12-08 04:16 ` Re: BUG #17706: ALTER TYPE leads to crash Richard Guo <guofenglinux@gmail.com>
  2022-12-08 05:01   ` Re: BUG #17706: ALTER TYPE leads to crash David G. Johnston <david.g.johnston@gmail.com>
@ 2022-12-13 02:58     ` Richard Guo <guofenglinux@gmail.com>
  2022-12-13 03:45       ` Re: BUG #17706: ALTER TYPE leads to crash David G. Johnston <david.g.johnston@gmail.com>
  2022-12-13 06:58       ` Re: BUG #17706: ALTER TYPE leads to crash Sergey Shinderuk <s.shinderuk@postgrespro.ru>
  0 siblings, 2 replies; 6+ messages in thread

From: Richard Guo @ 2022-12-13 02:58 UTC (permalink / raw)
  To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: s.shinderuk@postgrespro.ru; pgsql-bugs@lists.postgresql.org

On Thu, Dec 8, 2022 at 1:01 PM David G. Johnston <david.g.johnston@gmail.com>
wrote:

> We don't need to fix this though (i.e., make the query continue to somehow
> work), we need to detect the situation and return some kind of error as
> opposed to crashing the server.  The transaction itself is doing something
> illegal and can be forced to abort.  Alternatively, maybe the ALTER TYPE
> command can emit the error that it is unable to alter the type as it is
> already in use by the current session.  But that would close off possible
> non-problematic uses of ALTER TYPE in this situation
>

Yeah, that makes sense.  If we create a table using type foo, the alter
operation would error out like that.

create table t (a foo);

alter type foo alter attribute b type text;
ERROR:  cannot alter type "foo" because column "t.a" uses it

Maybe we can likewise record the dependencies for the type if it's being
used in other more scenarios besides as a column in some table?

Thanks
Richard

^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: BUG #17706: ALTER TYPE leads to crash
  2022-12-07 20:16 BUG #17706: ALTER TYPE leads to crash PG Bug reporting form <noreply@postgresql.org>
  2022-12-08 04:16 ` Re: BUG #17706: ALTER TYPE leads to crash Richard Guo <guofenglinux@gmail.com>
  2022-12-08 05:01   ` Re: BUG #17706: ALTER TYPE leads to crash David G. Johnston <david.g.johnston@gmail.com>
  2022-12-13 02:58     ` Re: BUG #17706: ALTER TYPE leads to crash Richard Guo <guofenglinux@gmail.com>
@ 2022-12-13 03:45       ` David G. Johnston <david.g.johnston@gmail.com>
  1 sibling, 0 replies; 6+ messages in thread

From: David G. Johnston @ 2022-12-13 03:45 UTC (permalink / raw)
  To: Richard Guo <guofenglinux@gmail.com>; +Cc: s.shinderuk@postgrespro.ru; pgsql-bugs@lists.postgresql.org

On Mon, Dec 12, 2022 at 7:58 PM Richard Guo <guofenglinux@gmail.com> wrote:

> Maybe we can likewise record the dependencies for the type if it's being
> used in other more scenarios besides as a column in some table?
>
>
The body of a pl/pgsql function is never going to be one of those scenarios
so that doesn't seem to be a useful path for fixing this bug.

David J.

^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: BUG #17706: ALTER TYPE leads to crash
  2022-12-07 20:16 BUG #17706: ALTER TYPE leads to crash PG Bug reporting form <noreply@postgresql.org>
  2022-12-08 04:16 ` Re: BUG #17706: ALTER TYPE leads to crash Richard Guo <guofenglinux@gmail.com>
  2022-12-08 05:01   ` Re: BUG #17706: ALTER TYPE leads to crash David G. Johnston <david.g.johnston@gmail.com>
  2022-12-13 02:58     ` Re: BUG #17706: ALTER TYPE leads to crash Richard Guo <guofenglinux@gmail.com>
@ 2022-12-13 06:58       ` Sergey Shinderuk <s.shinderuk@postgrespro.ru>
  1 sibling, 0 replies; 6+ messages in thread

From: Sergey Shinderuk @ 2022-12-13 06:58 UTC (permalink / raw)
  To: Richard Guo <guofenglinux@gmail.com>; David G. Johnston <david.g.johnston@gmail.com>; +Cc: pgsql-bugs@lists.postgresql.org

On 13.12.2022 05:58, Richard Guo wrote:
> If we create a table using type foo, the alter
> operation would error out like that.
> 
> create table t (a foo);
> 
> alter type foo alter attribute b type text;
> ERROR:  cannot alter type "foo" because column "t.a" uses it
> 
> Maybe we can likewise record the dependencies for the type if it's being
> used in other more scenarios besides as a column in some table?


Just in case, ALTER TABLE can also trigger the crash:

create table t (a int, b int);

create function f() returns t as $$
declare
	r t = (1, 2^30);
begin
	alter table t alter b type text;
	return r;
end;
$$ language plpgsql;

postgres=# select f();
server closed the connection unexpectedly


-- 
Sergey Shinderuk		https://postgrespro.com/






^ permalink  raw  reply  [nested|flat] 6+ messages in thread


end of thread, other threads:[~2022-12-13 06:58 UTC | newest]

Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-12-07 20:16 BUG #17706: ALTER TYPE leads to crash PG Bug reporting form <noreply@postgresql.org>
2022-12-08 04:16 ` Richard Guo <guofenglinux@gmail.com>
2022-12-08 05:01   ` David G. Johnston <david.g.johnston@gmail.com>
2022-12-13 02:58     ` Richard Guo <guofenglinux@gmail.com>
2022-12-13 03:45       ` David G. Johnston <david.g.johnston@gmail.com>
2022-12-13 06:58       ` Sergey Shinderuk <s.shinderuk@postgrespro.ru>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox