Re: BUG #17706: ALTER TYPE leads to crash

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: s(dot)shinderuk(at)postgrespro(dot)ru, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17706: ALTER TYPE leads to crash
Date: 2022-12-13 02:58:30
Message-ID: CAMbWs48eGK9YwbSprdwN4jWGeeC7xLLehb1ymFeZKFsTO9BmOg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Dec 8, 2022 at 1:01 PM David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Richard Guo 2022-12-13 03:20:42 Re: BUG #17713: Assert with postgres_fdw in v12
Previous Message David Rowley 2022-12-13 02:39:42 Re: BUG #17710: Slow queries (100% CPU) after auto-vacuum