Thread

Re: Bug with concurrent CREATE OR REPLACE (?)

Daniil Davydov <3danissimo@gmail.com> — 2025-06-26T17:23:59Z

Hi,

On Fri, Jun 27, 2025 at 12:05 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> This is operating as designed, more or less.  The error message isn't
> terribly user-friendly perhaps, but I think it's quite reasonable
> to throw an error.  Otherwise, which transaction's definition should
> win out?  The transactions are notionally operating at "the same
> time", so saying that either the first-to-insert or the last-to-insert
> ought to (silently) win isn't very satisfactory semantically.
> Certainly, if you imagined that this were being done under
> SERIALIZABLE transaction rules, you'd expect one of the transactions
> to error out.
>
> I actually think that the behavior is worse in the situation where
> the function already existed: in that case both transactions try
> to do an UPDATE, and one will fail with
>
> ERROR:  tuple concurrently updated
>
> which is even less user-friendly.  But again, this is about the
> usefulness of the error message, not about whether we need to
> avoid throwing any error.
>

OK, that sounds reasonable. Thanks!

> In short: CREATE OR REPLACE is not a substitute for thinking about
> how your application behaves.  Why do you need to have multiple
> transactions creating the same function at the same time?
>

Yep, I agree that this use case is bad, but some clients use such
logic and think that mentioned errors are a bug.
So I decided to clarify this moment.

--
Best regards,
Daniil Davydov