Andres Freund writes:
> On 2025-10-09 11:22:39 -0400, Tom Lane wrote:
>> Hmm, that is interesting -- I'd expect error cleanup to deal with
>> that. Did you happen to notice the exact repro case? It's surely
>> easy enough to add a pfree, but I don't believe that other errcontext
>> callbacks are
Hi,
On 2025-08-29 15:46:33 -0400, Tom Lane wrote:
> Hearing no comments beyond that one, pushed.
valgrind complains that there's a memory leak here:
==374853== 1,024 bytes in 1 blocks are definitely lost in loss record 1,257 of
1,459
==374853==at 0xFD902A: palloc (mcxt.c:1389)
==374853==
Andres Freund writes:
> On 2025-10-09 12:50:53 -0400, Tom Lane wrote:
>> Concretely, like the attached. This passes check-world, but
>> I can't test it under valgrind because I'm hitting the same
>> CREATE DATABASE failure skink is reporting.
> Sorry, was working on a fix when life rudely interv
Andres Freund writes:
> valgrind complains that there's a memory leak here:
> ==374853== 1,024 bytes in 1 blocks are definitely lost in loss record 1,257
> of 1,459
> ==374853==at 0xFD902A: palloc (mcxt.c:1389)
> ==374853==by 0x101A3D6: initStringInfoInternal (stringinfo.c:45)
> ==374853
Hi,
On 2025-10-09 13:33:44 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2025-10-09 12:50:53 -0400, Tom Lane wrote:
> >> Concretely, like the attached. This passes check-world, but
> >> I can't test it under valgrind because I'm hitting the same
> >> CREATE DATABASE failure skink is repo
Andres Freund writes:
> There are a few places that do
> ereport(...);
> /* Flush any strings created in ErrorContext */
> FlushErrorState();
> That'd be obsoleted by this change, right?
Oh, I see them, all in guc.c. Yeah, we should get rid of those;
they seem not too safe anyway g
I wrote:
> Andres Freund writes:
>> There are a few places that do
>> ereport(...);
>> /* Flush any strings created in ErrorContext */
>> FlushErrorState();
>> That'd be obsoleted by this change, right?
> Oh, I see them, all in guc.c. Yeah, we should get rid of those;
> they seem not too safe an
Hi,
On 2025-10-09 11:22:39 -0400, Tom Lane wrote:
> Andres Freund writes:
> > valgrind complains that there's a memory leak here:
>
> > ==374853== 1,024 bytes in 1 blocks are definitely lost in loss record 1,257
> > of 1,459
> > ==374853==at 0xFD902A: palloc (mcxt.c:1389)
> > ==374853==
I wrote:
> Yeah. I see that errfinish does FreeErrorDataContents in the
> non-ERROR code path, but of course that does nothing for random
> leakages during error processing. I'm tempted to have it do
> MemoryContextReset(ErrorContext) if we are at stack depth zero.
> That'd be unsafe during neste
Hi,
On 2025-10-09 12:50:53 -0400, Tom Lane wrote:
> I wrote:
> > Yeah. I see that errfinish does FreeErrorDataContents in the
> > non-ERROR code path, but of course that does nothing for random
> > leakages during error processing. I'm tempted to have it do
> > MemoryContextReset(ErrorContext) i
Dilip Kumar writes:
> On Fri, Jul 11, 2025 at 9:34 AM Zhang Mingli wrote:
>> May be confused if there were tables with same names under different schemas.
> If that's the only issue we can print schema qualified name, but I
> think the problem is in error callback we just have lock tag
> informa
On Fri, Jul 11, 2025 at 9:34 AM Zhang Mingli wrote:
>
> On Jul 11, 2025 at 11:36 +0800, Dilip Kumar , wrote:
>
>
> This seems to be quite useful to me, initially I thought if we can
> print the relation and database name then this could be even better
> but it might be a bad idea to fetch the obje
Hi,
On Jul 11, 2025 at 11:36 +0800, Dilip Kumar , wrote:
>
> This seems to be quite useful to me, initially I thought if we can
> print the relation and database name then this could be even better
> but it might be a bad idea to fetch the object name while we are in
> error callback.
May be conf
On Thu, Jul 10, 2025 at 10:36 PM Tom Lane wrote:
>
> I noted a complaint [1] about how hard it is to debug unforeseen
> lock-timeout failures: we give no details about what we were
> waiting for. It's not hard to improve that situation, at least
> to the extent of printing numeric locktag details
Hi,
On Jul 11, 2025 at 10:53 +0800, Tom Lane , wrote:
> Zhang Mingli writes:
> > Do we need to rollback error_context_stack to the previous state if we
> > enter the branch for PG_CATCH()?
>
> No. The PG_TRY mechanism itself deals with that: the next outer
> level of PG_TRY will restore error_co
Zhang Mingli writes:
> Do we need to rollback error_context_stack to the previous state if we enter
> the branch for PG_CATCH()?
No. The PG_TRY mechanism itself deals with that: the next outer
level of PG_TRY will restore error_context_stack to what it had
been. If this were not so, most other
Hi,
On Jul 11, 2025 at 01:06 +0800, Tom Lane , wrote:
> I noted a complaint [1] about how hard it is to debug unforeseen
> lock-timeout failures: we give no details about what we were
> waiting for. It's not hard to improve that situation, at least
> to the extent of printing numeric locktag detai
17 matches
Mail list logo
