Обсуждение: BUG #15327: postgres segfaults on ALTER FUNCTION ... SET SCHEMA ...

The following bug has been logged on the website:

Bug reference:      15327
Logged by:          Kai Kratz
Email address:      kai.kratz@googlemail.com
PostgreSQL version: 10.4
Operating system:   Ubunt18.04
Description:

I observed a 100% repeatable crash when doing the following:
pg-user=# CREATE SCHEMA test_schema;
CREATE SCHEMA
pg-user=# CREATE FUNCTION custom_eq(int, int)
RETURNS BOOL
LANGUAGE SQL IMMUTABLE AS
$$
SELECT $1 = $2;
$$;
CREATE FUNCTION
pg-user=# ALTER FUNCTION custom_eq(int, int) SET SCHEMA test_schema;
server closed the connection unexpectedly
    This probably means the server terminated abnormally
    before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>

Hello
Please try on latest minor 10.5 version. I can not reproduce with my 10.5 version.
Also show your log at the time of error.

postgres=# CREATE SCHEMA test_schema;
CREATE SCHEMA
postgres=# CREATE FUNCTION custom_eq(int, int)
postgres-# RETURNS BOOL
postgres-# LANGUAGE SQL IMMUTABLE AS
postgres-# $$
postgres$# SELECT $1 = $2;
postgres$# $$;
CREATE FUNCTION
postgres=# ALTER FUNCTION custom_eq(int, int) SET SCHEMA test_schema;
ALTER FUNCTION
postgres=# select test_schema.custom_eq(1,2);
 custom_eq 
-----------
 f

regards, Sergei

=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
> pg-user=# CREATE SCHEMA test_schema;
> CREATE SCHEMA
> pg-user=# CREATE FUNCTION custom_eq(int, int)
> RETURNS BOOL
> LANGUAGE SQL IMMUTABLE AS
> $$
> SELECT $1 = $2;
> $$;
> CREATE FUNCTION
> pg-user=# ALTER FUNCTION custom_eq(int, int) SET SCHEMA test_schema;
> server closed the connection unexpectedly

Huh.  Works fine for me.  Is the server you're using custom-built?
If so, what build options did you use?  If not, where did you get
it from?  In either case, the output of pg_config might be useful.

            regards, tom lane

Thanks for the very fast feedback,

It seems that I have an issue with an FDW extension that was loaded,
it didn't cross my mind that this could interfere with ALTER FUNCTION.
Same is true for the other 2 bug I filed a couple of minutes ago.

I am terribly sorry for creating unnecessary noise on pgsql-bugs. :(

Cheers
Kai Kratz
On Wed, Aug 15, 2018 at 3:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> =?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
> > pg-user=# CREATE SCHEMA test_schema;
> > CREATE SCHEMA
> > pg-user=# CREATE FUNCTION custom_eq(int, int)
> > RETURNS BOOL
> > LANGUAGE SQL IMMUTABLE AS
> > $$
> > SELECT $1 = $2;
> > $$;
> > CREATE FUNCTION
> > pg-user=# ALTER FUNCTION custom_eq(int, int) SET SCHEMA test_schema;
> > server closed the connection unexpectedly
>
> Huh.  Works fine for me.  Is the server you're using custom-built?
> If so, what build options did you use?  If not, where did you get
> it from?  In either case, the output of pg_config might be useful.
>
>                         regards, tom lane

Hi,

On 2018-08-15 16:08:51 +0200, Kai Kratz wrote:
> It seems that I have an issue with an FDW extension that was loaded,
> it didn't cross my mind that this could interfere with ALTER FUNCTION.
> Same is true for the other 2 bug I filed a couple of minutes ago.

Just for the record, which FDW was that?

- Andres

Hi Andres,

It is an in-house developed FDW. Part of the surprise was that we
execute the postgres integration tests (as described here:
https://www.postgresql.org/docs/current/static/regress-run.html)
against a postgres instance with our custom FDW loaded and no errors
show up.

Cheers
Kai
On Wed, Aug 15, 2018 at 5:19 PM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2018-08-15 16:08:51 +0200, Kai Kratz wrote:
> > It seems that I have an issue with an FDW extension that was loaded,
> > it didn't cross my mind that this could interfere with ALTER FUNCTION.
> > Same is true for the other 2 bug I filed a couple of minutes ago.
>
> Just for the record, which FDW was that?
>
> - Andres

Kai Kratz <kai.kratz@googlemail.com> writes:
> It is an in-house developed FDW. Part of the surprise was that we
> execute the postgres integration tests (as described here:
> https://www.postgresql.org/docs/current/static/regress-run.html)
> against a postgres instance with our custom FDW loaded and no errors
> show up.

Well, actually, it *is* pretty surprising that an FDW would affect
the behavior of ALTER FUNCTION.  Are you perhaps also hooking into
some parser hooks, or something else that's outside the FDW API?
Could you show us a backtrace from the segfault?

            regards, tom lane