On Fri, May 30, 2025 at 2:02 AM Tom Lane wrote:
> Finally, here's a minimalistic version of the original v1-0001
> patch that I think we could safely apply to fix the DirectModify
> problem in the back branches. I rejiggered it to not depend on
> inventing MemoryContextUnregisterResetCallback, so
Matheus Alcantara writes:
> Sounds reasonable to me. +1 for going forward with these patches.
I got cold feet about applying the full patchset to v18 --- it's
kind of a large change and it's not fixing any known bug that the
minimal patch doesn't, so it feels like something not to do after
beta1.
On Thu, May 29, 2025 at 2:02 PM Tom Lane wrote:
>
> I wrote:
> > Pushed v5-0001, and here are rebased versions of the other four
> > patches, mostly so that the cfbot knows what is the patch-of-record.
>
> Finally, here's a minimalistic version of the original v1-0001
> patch that I think we could
I wrote:
> Pushed v5-0001, and here are rebased versions of the other four
> patches, mostly so that the cfbot knows what is the patch-of-record.
Finally, here's a minimalistic version of the original v1-0001
patch that I think we could safely apply to fix the DirectModify
problem in the back bran
I wrote:
> Yeah, it's not intended to be done in that order: the v5-0001 patch is
> an independent thing. I anticipate I'll have to rebase the other
> patches after I push v5-0001.
Pushed v5-0001, and here are rebased versions of the other four
patches, mostly so that the cfbot knows what is the
Matheus Alcantara writes:
> The only point is that I've just tried to apply the v5-0001 on top of
> the previous v4-000X patches and is raising an error:
> git am v5-0001-Avoid-resource-leaks-when-a-dblink-connection-fai.patch
> Applying: Avoid resource leaks when a dblink connection fails.
> er
On 28/05/25 17:56, Tom Lane wrote:
> I wrote:
>> Having said that, the idea that this sequence is OOM-safe is pretty
>> silly anyway, considering that createNewConnection does a pstrdup,
>> and creates a new hashtable entry which might require enlarging the
>> hashtable, and for that matter might e
I wrote:
> Having said that, the idea that this sequence is OOM-safe is pretty
> silly anyway, considering that createNewConnection does a pstrdup,
> and creates a new hashtable entry which might require enlarging the
> hashtable, and for that matter might even create the hashtable.
> So maybe rath
Matheus Alcantara writes:
> I think that we can delay the allocation a bit more. The
> dblink_security_check just use the rconn to pfree in case of a failure,
> so I think that we can remove this parameter and move the rconn
> allocation to the next if (connname) block. See attached as an example.
Hi,
On 26/05/25 16:36, Tom Lane wrote:
> Here's a v4 that is actually more or less feature-complete:
> it removes no-longer-needed complexity such as PG_TRY blocks.
> I've checked that Valgrind shows no leaks in the postgres_fdw
> and dblink tests after applying this on top of my other
> patch ser
Here's a v4 that is actually more or less feature-complete:
it removes no-longer-needed complexity such as PG_TRY blocks.
I've checked that Valgrind shows no leaks in the postgres_fdw
and dblink tests after applying this on top of my other
patch series.
0001 is like the previous version except tha
I wrote:
> Here is an attempt at making a bulletproof fix by having all backend
> users of libpq go through a wrapper layer that provides the memory
> context callback. Perhaps this is more code churn than we want to
> accept; I'm not sure. I thought about avoiding most of the niggling
> code cha
Etsuro Fujita writes:
> On Sat, May 24, 2025 at 10:10 AM Tom Lane wrote:
>> I thought of fixing this by using a memory context reset callback
>> to ensure that the PGresult is cleaned up when the executor's context
>> goes away, and that seems to work nicely (see 0001 attached).
>> However, I fee
Hi,
On Sat, May 24, 2025 at 10:10 AM Tom Lane wrote:
> The DirectModify code path relies on PG_TRY blocks to ensure that it
> releases the PGresult for the foreign modify command, but that can't
> work because (at least in cases with RETURNING data) the PGresult has
> to survive across successive
14 matches
Mail list logo
