Re: Looks heap_create_with_catalog ignored the if_not_exists options

From: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Looks heap_create_with_catalog ignored the if_not_exists options
Date: 2019-03-01 16:15:19
Message-ID: CAKU4AWqENDfGP3mi605WF9pxMQin_x8AveWXG3C-Yx=bvFONUg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thank you Michael!

What can I do if I'm sure I will not use the CTAS creation ? Take a look
at the "heap_create_with_catalog" function, it check it and raise error.
Even I change it to "check it && if_not_existing", raise error, it is
still be problematic since we may some other session create between the
check and the real creation end.

Looks we need some locking there, but since PG is processes model, I even
don't know how to sync some code among processes in PG (any hint on this
will be pretty good as well).

On Fri, Mar 1, 2019 at 8:35 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Fri, Mar 01, 2019 at 07:17:04PM +0800, Andy Fan wrote:
> > for a createStmt, it will call transformCreateStmt, and then
> > heap_create_with_catalog.
> > but looks it just check the if_not_exists in transformCreateStmt.
> >
> > is it designed as this on purpose or is it a bug?
>
> That's a bug. Andreas Karlsson and I have been discussing it a couple
> of days ago actually:
> https://www.postgresql.org/message-id/20190215081451.GD2240@paquier.xyz
>
> Fixing this is not as straight-forward as it seems, as it requires
> shuffling a bit the code related to a CTAS creation so as all code
> paths check at the same time for an existing relation. Based on my
> first impressions, I got the feeling that it would be rather invasive
> and not worth a back-patch.
> --
> Michael
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-03-01 16:17:25 Re: SQL/JSON: JSON_TABLE
Previous Message Antonin Houska 2019-03-01 16:14:25 Re: Problems with plan estimates in postgres_fdw