| From: | Antonin Houska <ah(at)cybertec(dot)at> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Noah Misch <noah(at)leadboat(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net> |
| Subject: | Re: Adding REPACK [concurrently] |
| Date: | 2026-04-07 09:35:50 |
| Message-ID: | 193024.1775554550@localhost |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> On 2026-Apr-07, Antonin Houska wrote:
>
> > I haven't thought of this explanation because BufFileWrite() only copies the
> > data to a buffer in the BufFile structure and BufFileDumpBuffer() writes the
> > buffer. Maybe valgrind is able to track the copying?
>
> Yeah, apparently it keeps track of tainted bytes somehow. Clever.
>
> The change to palloc0() that I was proposing did not fix the problem,
> because the stack allocated struct overwrote those zeroes with the
> uninitialized padding bytes.
>
> I ended up with an equivalent fix to Srinath's -- zero-initializing
> the stack-allocated struct, so that the bytes that end up copied by
> memcpy() are all defined. Srinath confirmed that in his environment the
> valgrind failure goes away, so I think we're good.
Thanks!
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Antonin Houska | 2026-04-07 09:39:12 | Re: Adding REPACK [concurrently] |
| Previous Message | Tomas Vondra | 2026-04-07 09:32:28 | Re: EXPLAIN: showing ReadStream / prefetch stats |