From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dmitry Astapov <dastapov(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17619: AllocSizeIsValid violation in parallel hash join |
Date: | 2022-09-27 21:16:41 |
Message-ID: | CAH2-WznE_8vaUfhC=PPu-=E4FV=VB_9JXZCEn28WZd2byHdvXA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Sep 27, 2022 at 12:15 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > I believe that Thomas was going to do something like this anyway. I'm
> > happy to leave it up to him, but I can pursue this separately if that
> > makes sense.
>
> Why not clobber "lower down" in dsm_create(), as I showed? You don't
> have to use the table-of-contents mechanism to use DSM memory.
I have no strong feelings either way. That approach might well be better.
It might even be useful to do both together. The redundancy probably
wouldn't hurt, and might even help in the future (it might not stay
redundant forever). We don't necessarily need to worry too much about
added cycles for something like this. Just as long as it's not
*completely* gratuitous.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-09-27 23:24:44 | Re: Function modification visibility in parallel connection |
Previous Message | Thomas Munro | 2022-09-27 19:15:19 | Re: BUG #17619: AllocSizeIsValid violation in parallel hash join |