| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Zhang Mingli <zmlpostgres(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Steve Baldwin <steve(dot)baldwin(at)gmail(dot)com> |
| Subject: | Re: Adding some error context for lock wait failures |
| Date: | 2025-10-09 15:22:39 |
| Message-ID: | 2952775.1760023359@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> 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== by 0x101A46B: initStringInfo (stringinfo.c:99)
> ==374853== by 0xD8CF32: waitonlock_error_callback (lock.c:2027)
> ==374853== by 0xF916E2: errfinish (elog.c:510)
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 any more careful than this one.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Euler Taveira | 2025-10-09 15:22:59 | Re: Invalid pointer access in logical decoding after error |
| Previous Message | Jacob Champion | 2025-10-09 15:21:56 | Re: Support getrandom() for pg_strong_random() source |