On 2024-Dec-02, Amit Kapila wrote:
> We already have PGOutputData->cachectx which could be used for it.
> I think we should be able to reset such a context when we are
> revalidating the publications.
I don't see that context being reset anywhere, so I have a hard time
imagining that this would work without subtle risk of breakage
elsewhere.
> Even, if we want a new context for some localized handling, we should
> add that in PGOutputData rather than a local context as the proposed
> patch is doing at the very least for HEAD.
I don't necessarily agree, given that this context is not needed
anywhere else.
> Can't we consider freeing the publication names individually that can
> be backpatchable and have no or minimal risk of breaking anything?
That was my first thought, but then it occurred to me that such a thing
would be totally pointless.
> > you call anything that loads a Publication depending on how the caller
> > caches its data. So I would still choose for modifying the structure
> > on HEAD removing the pstrdup() for the publication name.
>
> BTW, the subscription structure also used the name in a similar way.
> This will make the publication/subscription names handled differently.
True (with conninfo, slotname, synccommit, and origin).
FWIW it seems FreeSubscription is incomplete, and not only because it
fails to free the publication names ...
(Why are we storing a string in Subscription->synccommit?)
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Los trabajadores menos efectivos son sistematicamente llevados al lugar
donde pueden hacer el menor daño posible: gerencia." (El principio Dilbert)
