Re: pgsql: CREATE SUBSCRIPTION ... SERVER.

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Jeff Davis <jdavis(at)postgresql(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: CREATE SUBSCRIPTION ... SERVER.
Date: 2026-03-13 20:37:29
Message-ID: 44cbdf50807b0232d0a01f0fababc7cbeeb33eb0.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On Fri, 2026-03-13 at 09:54 -0400, Andres Freund wrote:
> GetSubscription() does a dozen allocations or so, so I'm not sure it
> matters
> that ForeignServerConnectionString() would do another few. There is
> FreeSubscription(), but it only seems to free a subset of the
> allocations, and
> none of the temporary allocations that are surely made below
> GetSubscription().

That by itself seems like a problem. If FreeSubscription() is needed,
then it should do its job; and if it's not needed, then it should be
eliminated.

To me it looks like it's needed. Otherwise there will be leaks for
every invalidation.

> But regardless of that, even if you want to make
> ForeignServerConnectionString() not leak, I don't think that means
> you need to
> use PG_TRY/FINALLY. If there's an error, afaict the callers will just
> throw
> away the apply context, no? Otherwise there'd likely be way more
> problems.

I believe that's correct. While there's no delete or reset, it looks
like an error will cause the worker to exit/restart.

> So
> just create the context without a PG_TRY and delete it in the success
> case.
> In the failure case it'll be cleaned up by error handling.

Thank you, patch attached.

> And if you do need the PG_TRY for some reason, why not do the
> text_to_cstring() call inside the PG_TRY, since it never can have a
> value if
> an error was thrown?

That's what I did in the patch I posted here:

https://www.postgresql.org/message-id/f48610c90e69de4b30841361c568c3765e8f3dfe.camel%40j-davis.com

but I think you are right that we don't need the try/catch at all.

Regards,
Jeff Davis

Attachment Content-Type Size
v22-0001-Eliminate-PG_TRY-PG_CATCH-in-ForeignServerConnec.patch text/x-patch 3.0 KB

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2026-03-13 20:48:34 Re: pgsql: CREATE SUBSCRIPTION ... SERVER.
Previous Message Nathan Bossart 2026-03-13 20:05:07 pgsql: Add convenience view to stats import test.