Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION

On Thu, 5 Jun 2025 16:26:08 +0900
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> wrote:

> On Tue, 3 Jun 2025 17:39:50 +0900
> Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> wrote:
>
> > On Tue, 27 May 2025 09:00:01 +0300
> > Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
>
> > I know there are other scenarios where the same is raises and I agree that
> > it would be better to consider a more global solution instead of addressing
> > each of them. However, I am not sure that improving the error message for
> > each case doesn't not make sense.
>
> To address the remaining cases where DDL commands fail with the internal
> error "ERROR: tuple concurrently updated" due to insufficient locking,
> I would like to propose improving the error reporting to produce a more
> appropriate and user-facing error message. This should make it easier for
> users to understand the cause of the failure.
>
> Patch 0003 improves the error message shown when concurrent updates to a
> system catalog tuple occur, producing output like:
>
> ERROR: operation failed due to a concurrent command
> DETAIL: Another command modified the same object in a concurrent session.
>
> Patches 0001 and 0002 are unchanged from v2, except for updated commit messages.
> I believe these patches are still useful, as they allow the operation to complete
> successfully after waiting, or to behave appropriately when the target function
> is dropped by another session during the wait.

I found that the error "tuple concurrently updated" was expected as the results
of injection_points test , so I've fixed it so that the new message is expected
instead.

I've attached updated patches.

Best regards,
Yugo Nagata

--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>